intercompany data exchange

..... ..... Page 1 of 153

CookbookCookbookCookbookCookbook Intercompany Data ExchangeIntercompany Data ExchangeIntercompany Data ExchangeIntercompany Data Exchange

Status:

IS-U 4.63

SAP AG Cookbook IDE Page 2 of 153

Cookbook Intercompany Data Exchange Copyright Copyright 2001 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390, and OS/400 are registered trademarks of IBM Corporation. ORACLE is a registered trademark of ORACLE Corporation. INFORMIX-OnLine for SAP and Informix Dynamic Server

TM are registered trademarks of Informix Software

Incorporated. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.


Cookbook Intercompany Data Exchange

CONTENTS

1 INTRODUCTION............................................................................................................................7 1.1 Target Group and Topics Covered by Cookbook .......................................................................7 1.2 Releases.....................................................................................................................................7 1.3 Terms..........................................................................................................................................8 1.4 IDE Overview............................................................................................................................10

1.4.1 Constituent Parts of the IDE Component ...........................................................................10 1.4.2 Predefined Process Flows..................................................................................................11 1.4.3 IDoc Interface.....................................................................................................................11

1.5 Comparison with Energy Data Management ............................................................................12 2 BASIC IMPLEMENTATION CONSIDERATIONS .......................................................................13 2.1 System Landscape ...................................................................................................................13 2.2 Scenario Landscape .................................................................................................................13 3 CENTRAL ENTITIES IN IDE .......................................................................................................14 3.1 Data Model................................................................................................................................14 3.2 Point of Delivery........................................................................................................................14

3.2.1 Description .........................................................................................................................14 3.2.2 Data Model.........................................................................................................................15 3.2.3 Maintenance.......................................................................................................................15

3.3 Grid ...........................................................................................................................................16 3.3.1 Description .........................................................................................................................16 3.3.2 Data Model.........................................................................................................................18 3.3.3 Maintenance.......................................................................................................................19

3.4 Services ....................................................................................................................................21 3.4.1 Description .........................................................................................................................21 3.4.2 Data Model.........................................................................................................................22 3.4.3 Maintenance.......................................................................................................................22

3.5 Service Provider........................................................................................................................24 3.5.1 Description .........................................................................................................................24 3.5.2 Data Model.........................................................................................................................25 3.5.3 Maintenance.......................................................................................................................25

3.6 Deregulation Data in IS-U Master Data ....................................................................................28 3.6.1 Relevant Fields in the Installation.......................................................................................28 3.6.2 Relevant Fields in the Contract ..........................................................................................29 3.6.3 Relevant Fields in NB Services ..........................................................................................33 3.6.4 Possible Deregulation Scenarios .......................................................................................35

3.6.4.1 Example 1: Supplier as Billing Agent and Rate Ready ..................................................................... 36 3.6.4.2 Example 2: Distributor as Billing Agent and Bill Ready ..................................................................... 38 3.6.4.3 Example 3: Supplier as Sole Provider ............................................................................................... 39 3.6.4.4 Example 4: Dual Billing ...................................................................................................................... 41

4 STATIC BUSINESS PROCESSES..............................................................................................42 4.1 Sending and Receiving Consumption Data ..............................................................................42

4.1.1 Prerequisites ......................................................................................................................42 4.1.2 Outbound ...........................................................................................................................43 4.1.3 Inbound ..............................................................................................................................45



4.1.4 Reversal .............................................................................................................................46 4.1.4.1 Outbound............................................................................................................................................ 46 4.1.4.2 Inbound............................................................................................................................................... 47

4.1.5 Restrictions and Outlook ....................................................................................................47 4.2 Sending and Receiving Billing Data..........................................................................................48

4.2.1 Outbound ...........................................................................................................................48 4.2.1.1 Bill Ready............................................................................................................................................ 48 4.2.1.2 Rate Ready......................................................................................................................................... 50

4.2.2 Inbound ..............................................................................................................................50 4.2.2.1 Billing Agent........................................................................................................................................ 50 4.2.2.2 Sole Provider...................................................................................................................................... 53 4.2.2.3 Outlook: Creating a Bill Manually....................................................................................................... 54

4.2.3 Reversal .............................................................................................................................54 4.2.3.1 Outbound............................................................................................................................................ 54 4.2.3.2 Inbound............................................................................................................................................... 54

4.2.4 Sending Manual Billing Documents....................................................................................54 4.3 Sending and Receiving Payment Advice Notes........................................................................56

4.3.1 Outbound ...........................................................................................................................56 4.3.2 Inbound ..............................................................................................................................58 4.3.3 Reversal .............................................................................................................................58

4.4 Periodic Billing...........................................................................................................................59 4.4.1 Example 1: Supplier as Billing Agent with Rate Ready ......................................................60 4.4.2 Example 2: Distributor as Billing Agent with Bill Ready......................................................61 4.4.3 Example 3: Supplier as Sole Provider................................................................................62 4.4.4 Cross Reference Number ..................................................................................................63

5 DYNAMIC BUSINESS PROCESSES..........................................................................................65 5.1 Change of Supplier ...................................................................................................................65

5.1.1 New Supplier ......................................................................................................................66 5.1.1.1 Manual Enrollment ............................................................................................................................. 67 5.1.1.2 Services Based on Operational Area................................................................................................. 67 5.1.1.3 Services Based on Service Provider Relationship ............................................................................ 74 5.1.1.4 Automatic Enrollment......................................................................................................................... 80

5.1.2 Former Suppliers Perspective ...........................................................................................94 5.1.3 Distributors Perspective.....................................................................................................95

5.1.3.1 Function Modules for Change of Service and Scenario.................................................................... 98 5.1.3.2 Contract Change .............................................................................................................................. 100 5.1.3.3 Procedure for Change Process ....................................................................................................... 100

5.2 Service Notification .................................................................................................................102 5.2.1 General ............................................................................................................................102 5.2.2 Process ............................................................................................................................102 5.2.3 Implementation.................................................................................................................102

5.2.3.1 Record Service Notification.............................................................................................................. 102 5.2.3.2 Communication ................................................................................................................................ 103 5.2.3.3 Processing the Confirmation............................................................................................................ 104

5.3 Master Data Change...............................................................................................................104 5.3.1 Outbound .........................................................................................................................104 5.3.2 Inbound ............................................................................................................................105

6 COMMUNICATION CONTROL.................................................................................................106 6.1 Basics of Communication .......................................................................................................106 6.2 Basics of Communication Control...........................................................................................107

6.2.1 Define Control Parameters...............................................................................................107 6.2.2 Define Processing Events ................................................................................................108



6.2.3 Activate Processing Events..............................................................................................108 6.2.4 Define Function Modules for Processing Events..............................................................109 6.2.5 Define Communication Based on Service Types.............................................................109 6.2.6 Define Communication Based on Service Providers........................................................111

6.3 Process Management for Outbound Communication.............................................................113 6.3.1 Event Module ...................................................................................................................113 6.3.2 Process Module................................................................................................................114

6.4 Process Management for Inbound Communication................................................................115 6.4.1 Event Module ...................................................................................................................115 6.4.2 Process Module................................................................................................................116

7 INTEGRATION OF EDM FUNCTIONS .....................................................................................117 7.1 Prerequisites...........................................................................................................................117 7.2 Sending Load Shapes and Schedules from Settlement .........................................................117 7.3 Sending Any Profiles (Interval Meter) .....................................................................................118 7.4 Receiving Load Shapes and Schedules .................................................................................118 8 OTHER SPECIAL FEATURES..................................................................................................119 8.1 Changing From a Regulated to Deregulated Company..........................................................119 8.2 Company Without Their Own Billable Service ........................................................................120

8.2.1 Example 1: Meter Operator..............................................................................................120 8.2.2 Example 2: Rate Ready Scenario ....................................................................................121

9 SUPPLIER AND DISTRIBUTOR IN ONE SYSTEM..................................................................122 9.1 Recommendation: Separate Clients .......................................................................................122 9.2 Functional Special Features ...................................................................................................122 9.3 Example Scenarios .................................................................................................................123

9.3.1 Example 1: Strict Separation............................................................................................123 9.3.2 Example 2: Separation Only When Necessary................................................................123

10 FUNCTIONAL ENHANCEMENTS .........................................................................................124 10.1 Changes to Existing Processes...........................................................................................124

10.1.1 Changing Processing of Outbound Messages .............................................................124 10.1.2 Changing Processing of Inbound Messages ................................................................124

10.2 Adding a New Process ........................................................................................................125 10.2.1 New Processes for Outbound Messages .....................................................................125 10.2.2 New Processes for Inbound Messages ........................................................................125

10.3 Standard Enhancements.....................................................................................................126 11 GENERAL ..............................................................................................................................127 11.1 Performance........................................................................................................................127 11.2 Data Volume and Archiving .................................................................................................127 11.3 Migration..............................................................................................................................127

11.3.1 Transfer Concept for Points of Delivery and Point of Delivery Services .......................127 11.3.1.1 Process Flow for Deregulated Installations ..................................................................................... 128 11.3.1.2 Process Flow for Non-Deregulated Installations ............................................................................. 128

11.3.2 Installation.....................................................................................................................128 11.3.2.1 Migration Object INSTLN................................................................................................................. 128 11.3.2.2 Migration Object INSTLNCHA ......................................................................................................... 129

11.3.3 Point of Delivery............................................................................................................130 11.3.3.1 Migration Object POD ...................................................................................................................... 130 11.3.3.2 Migration Object PODCHANGE ...................................................................................................... 131



11.3.4 NB Services ..................................................................................................................131 11.3.4.1 Migration Object PODSERVICE...................................................................................................... 131

11.4 Problem of Duplicate Device Numbers................................................................................133 11.5 Statistics ..............................................................................................................................133 12 APPENDIX..............................................................................................................................134 12.1 Business Add-Ins.................................................................................................................134 12.2 SAP Enhancements ............................................................................................................135 12.3 Important Function Modules ................................................................................................136

12.3.1 ISU_SCENARIO_DETERMINE....................................................................................136 12.3.2 ISU_IDE_SCENARIO ...................................................................................................136 12.3.3 ISU_ANALYSE_CONTRACT_FOR_EDI......................................................................136 12.3.4 ISU_SERVICE_PROVIDER_READ .............................................................................136 12.3.5 ISU_COM_EVENTS_DISABLE_IDE............................................................................136 12.3.6 ISU_COM_EVENTS_ENABLE_IDE.............................................................................136

12.4 Processes and Events.........................................................................................................136 12.5 IDocs ...................................................................................................................................141

12.5.1 Outbound View .............................................................................................................141 12.5.2 Inbound View ................................................................................................................144

12.6 Scenarios.............................................................................................................................147



1 Introduction

1.1 Target Group and Topics Covered by Cookbook This cookbook is aimed at implementation project teams responsible for installing the Intercompany Data Exchange (IS-U-IDE) component. It is assumed that readers understand the processes and requirements of the deregulated market, and that they are familiar with the IS-U data model and the basic processes in the IS-U and FI-CA components. The cookbook is not intended to replace a training course. However, since it contains explanations of the various models and terms, it can be used in combination with the documentation in the Implementation Guide (IMG) to obtain a good insight into the component. The IDE component is designed flexibly to allow companies to map a wide variety of deregulated market models. Since it was not possible to cover all the different models in this cookbook, most of the scenarios described here are based on a market in which the distributor and the supplier are the only participants in the deregulated market. Additional marketplace participants, such as a clearing house, a settlement coordinator or a meter operator, are added in some units where this is required to explain certain settings.

1.2 Releases Deregulation functions have been available in IS-U since Release 1.2, although the scope of these functions is very limited up to and including 4.61. For this reason, SAP did not deliver the IDE component in any Releases prior to and including 4.61. If you are in doubt as to the availability of IDE, please contact your local international subsidiary. The component was reworked for Release 4.62, providing functions for general availability. The objects point of delivery and service were introduced to take account of the requirements of the deregulated market. Release 4.63 furthered the changes begun in 4.62. The most important new addition to the data model was the object grid. We recommend that you use Release 4.63 as a basis for implementing IDE, particularly if you are also implementing the Energy Data Management (IS-U-EDM) component. Due to high demand for this component, 4.63 will also contain further developments, particularly with regard to requirements on the German market. Thanks to its general focus, the standard 4.63 version (with Support Package 2) supports the German Associations Agreement Regarding Electric Energy (VV2), although the implementation project involves further development of this function in order to take account of market- and company-specific requirements. The information provided in this cookbook is in no way binding and does not constitute a development commitment.



1.3 Terms Abbreviations: NB service Non-billable service CRN Cross-reference number Definitions: Advance payment Procedure whereby the billing agent pays the service provider for the

outstanding receivables, even if the customer has not yet paid the billing agent. The billing agent owns the receivables from the customer once they have been invoiced in IS-U.

Bill ready Bill creation process performed by the service provider, in which they are the owner of the receivable. The bill covers services performed by the service provider as well as services from any third parties involved. The bill is transferred to the billing consolidator, who is responsible for bill payment. This means the customer receives one bill for all service types.

Billing agent Service provider who creates bills and monitors incoming payments both for services they provide themselves and for services provided by third parties. Receivables for which the customer is billed on behalf of third parties are forwarded directly to the third party and do not appear (as revenue) in the billing agents general ledger.

Billing consolidator Service provider who bills the customer for several services. This is an umbrella term for billing agent and sole provider.

Customer payment Procedure whereby the billing agent only pays outstanding receivables to the service provider once the customer has paid the outstanding receivables to the billing agent.

Deregulation scenario Description of a valid relationship between service providers in the deregulated market. To simplify matters, the scenarios are not always described in full in this documentation. For example, when a sole provider scenario is mentioned, it is not clear whether the sole provider is the distributor or the supplier, or when a billing agent scenario is mentioned, the scenario may involve a bill ready or rate ready procedure with advance payment or customer payment. If the exact scenario is irrelevant in a particular context, general references like these are used.

Grid Object in the IS-U System that corresponds to a distribution grid or part of one.

Rate ready Bill creation process and bill payment by the billing consolidator on behalf of the service provider who is the service owner. The billing consolidator must have access to all the necessary data (for example, rate data) in order to create the bill. This means the customer receives one bill for all service types.


Cookbook Intercompany Data Exchange Service provider Company that provides, for example, one of the following services

(service types): Energy generation Energy purchasing Energy switching Energy distribution Meter installation and maintenance Meter reading

A service provider is assigned one service type. Sole provider Service provider solely responsible for all services, from the customers

point of view. The sole provider is also the owner of third-party receivables from the customer. All receivables for which the customer is billed are listed as revenue in the sole providers general ledger.

Templates SAP provides predefined programs and workflows for some process flows. These are supplied as templates. SAP delivers the following templates: IDocs Programs for entering data in IDocs for outbound messages Programs for reading IDocs for inbound messages and subsequent

processing Workflows for more complex process management

Point of delivery Point at which a utility service is performed or determined for a customer. A point of delivery has one (or in some cases no) external number (point of delivery ID) at one time. A point of delivery is used for:

Communication in automatic data exchange (deregulation point of delivery)

Exchange of meter reading results (technical point of delivery)

When exchanging meter reading results, the technical point of delivery has the following categories:

Standard point of delivery Virtual point of delivery



1.4 IDE Overview

1.4.1 Constituent Parts of the IDE Component IDE is primarily comprised of the following parts:

IDE

Administration of deregulation data

Communicationcontrol

Process management

Administration of deregulation data

Deregulation data includes points of delivery, grids, point of delivery services and service providers.

Communication control Communication control allows you to send and receive data for certain events. Data recorded in the point of delivery allows you to determine the communication partner according to flexible criteria and to determine the information to be sent and received and the format to be used.

Process management Process management allows you to trigger processes for inbound communication: simple processes such as changes to business partner master data, as well as a complex workflow for processing enrollment. Outbound communication does not usually require complex process management. Many existing IS-U processes trigger outbound communication. For this reason, communication events have been created in the standard IS-U System. These trigger communication in accordance with the Customizing settings. For a list of inbound and outbound events and the relevant programs, refer to the appendix.



1.4.2 Predefined Process Flows Deregulation data, communication control and the general SAP tools Workflow, Business Communication using IDocs and the Development Workbench constitute a set of tools that meet the requirements of an implementation project. To further simplify your job, SAP provides predefined programs and workflows for a number of process flows, as well as a large number of other tables that are required for coordinated interaction between communication partners. SAP delivers the following templates: IDocs

For a list of the IDoc templates delivered with the standard system, see the appendix (Unit 12).

Programs for entering data in IDocs for outbound messages To find out which programs enter data in which IDocs, see the appendix (Unit 12)

Programs for reading IDocs for inbound messages and subsequent processing To find out which programs process which IDocs, see the appendix (Unit 12).

Workflows for more complex process management These are described in Unit 5.1 (Change of Supplier).

We recommend that you copy the standard templates and modify them to meet your companys requirements. The templates provided up to and including Release 4.62 support the North American market (Pennsylvania model, Texas model). As of Release 4.63, templates also exist for the Swedish and German markets. The templates provided for the German market with 4.63 are restricted to sending and receiving messages in MSCONS1 and DELFOR2 format. The existing templates are also valuable for copying. The process flows are often similar, the only difference being the data transfer format, so that it is relatively easy to copy an existing template and modify it according to your requirements.

Note Further developments supporting the German Associations Agreement Regarding Electric Energy are planned, in particular to support other message formats.

Note that some templates were programmed for a certain deregulation scenario (distributor as billing agent, that is, dual contract model), whereas others can be used flexibly for different scenarios (billing agent or sole provider).

1.4.3 IDoc Interface The IDE component (that is to say, the parts described above and the templates) is designed for standardized electronic communication using IDocs, which is for the most part automated. If these standards are missing or the information is transferred without formatting (for example, by post, fax or telephone), you must enter the data manually before the processes can be started. This manual process does not pose a problem, provided the existing standard functions are sufficient, as is, for example, the case when changing business partner data or recording meter reading results.

1. 1 EDIFACT Message category used for sending consumption data and load shapes. 2. 2 EDIFACT Message category used for sending schedules.


Cookbook Intercompany Data Exchange However, if subsequent steps that necessitate integration in a superordinate process are required, you must create the data entry screens needed for this purpose in the implementation project. The standard interface for IDE is the IDoc. We recommend that you use this interface, even if communication is actually to take place using non-standard media. An IDoc allows you to convert outbound communication to different formats, such as XML, EDIFACT3, MS Excel, e-mail, and fax. When receiving unformatted data, we recommend that you convert the format after you have entered the data manually in an IDoc if standards exist for the same data but their use is not predefined. You can also change the standard templates so that the system uses an interface of your choice instead of the IDocs and enters the data in an MS Excel table.

1.5 Comparison with Energy Data Management In the Energy Data Management (IS-U-EDM) component, you can manage interval-related data (such as energy consumption and prices) using profiles, which then form the basis for the settlement procedure used to create aggregated load shapes4 or schedules according to different settlement procedures5.

Note For further information on Energy Data Management, access the SAP Help Portal http://help.sap.com/ under mySAP.com Industry Solutions mySAP Utilities. Here, you will also find documentation on the current release in English and German.

The components IS-U-EDM and IS-U-IDE are linked by a functional interface in such a way that the data stored in EDM or determined during settlement is communicated to and received by other marketplace participants. The interaction between these two components ensures that many of the requirements in the deregulated market are met effectively.

3. 3 Electronic Data Interchange for Administration, Commerce and Trade. 4. 4 Consumption measured by interval meters that is stored in an elementary profile. 5. 5 Procedure used to balance energy supplied and energy consumed that is carried out by

settlement coordinator.



2 Basic Implementation Considerations Before you begin with a detailed conception of the processes and the related Customizing settings, determine the following: System landscape in which IDE is to be implemented Deregulation scenarios that must be supported

2.1 System Landscape In addition to the usual considerations regarding system landscape when implementing SAP software, deregulated markets give rise to further considerations for companies that operate as a number of separate enterprises. A typical example of this would be a distributor and a supplier who both belong to the same holding. The question of whether both enterprises should be run in the same client, in different clients, or even in different systems, depends on a number of factors. One of the most important factors is the legislation of the country in question. In most countries, suppliers are not allowed to gain advantage from the fact that they share the same IT system as their own distributor. However, the instructions as to how this is to be implemented are often unclear. We recommend that you use different systems or clients for the following reasons: If legislation becomes stricter in the future and separate systems are required, you will avoid an

expensive, complex and time-consuming conversion procedure. Potential authorization problems are avoided. Use of a single client is also supported. For special notes on this, see unit 9 (Supplier and Distributor in Same System).

2.2 Scenario Landscape You should define the relevant deregulation scenarios in good time so that you can determine the scope of the processes involved and the flexibility required. You may require scenarios unlike any of those described in this cookbook. Particularly the involvement of other marketplace participants, such as billing companies or meter operators, results in a variety of new scenario combinations. For more information on this topic, see unit 3.6 (Deregulation Data in IS-U Master Data).



3 Central Entities in IDE This unit describes the technical model and maintenance of the data objects.

3.1 Data Model The data model displayed below is a simplified diagram without the relationships between the objects.

Serviceprovider

Servicenot

billable

Point ofdelivery Installation

DeviceRegister

Premise

Contractbillableservice

Contractaccount

Businesspartner

Connectionobject

Regionalstructure

Grid

Default value

Dis

tribu

tor

Deregulated

Technical

Serv

ice

cat.

Dis

tribu

tion

3.2 Point of Delivery

3.2.1 Description The point of delivery is the central object in the deregulated data model. There are two types of point of delivery: 1. Deregulation point of delivery 2. Technical point of delivery Only the deregulation point of delivery is relevant to IDE. This means that wherever a point of delivery is mentioned in this documentation, the reference is to a deregulation point of delivery.


Cookbook Intercompany Data Exchange A deregulation point of delivery is created automatically for every installation. The point of delivery ID is used to identify each point of delivery uniquely for communication. You can also search in the Data Finder using the point of delivery ID. Even if there are no points of delivery defined in a market or definition has not been carried out comprehensively, communication is still possible. For communication with other service providers, you must simply ensure that other definitive identifying criteria exist. This means it is also possible to support communication in these markets. A point of delivery can be allocated several services. The point of delivery is also allocated to a grid. All relationships between the point of delivery and other objects are recorded as a history.

3.2.2 Data Model

ServiceNon-

billable

Point ofdelivery

Installation

Register

Deregulation role

Technical

rolePoint of

delivery ID

Example: by metering code DE 4711 69190 1234567890

Grid

3.2.3 Maintenance A deregulation point of delivery is created automatically when you create an installation. The installation transaction includes a subscreen for maintaining the point of delivery. You can enter the point of delivery ID, a validity period, and the installation allocation on this screen. It is also possible to allocate more than one installation to the same point of delivery. To do this, you enter the same point of delivery ID when creating the installations and the following criteria must be met: The installations must belong to the same premise The installations must have service types that reference different service categories


Cookbook Intercompany Data Exchange Detailed maintenance of the data on the point of delivery is possible using the point of delivery transaction, available under Utilities Industry Technical Master Data Point of Delivery.

Note For a detailed description on the maintenance procedure and settings for the point of delivery, see the SAP Service Marketplace http://service.sap.com. Choose Enter now and log on with your user and password. Then choose Solution Details Industry Solutions mySAP Utilities Media Center IS-U/CCS Core Components Cookbooks Cookbook Point of Delivery.

3.3 Grid

3.3.1 Description A grid is an object in the IS-U System that corresponds to the distribution grid or part of it. You can manage grids for a distributor. A distributors distribution grid can be divided up into several grids for the following reasons: To record grid hierarchies The distribution grid covers several control areas The distribution grid is divided up into several voltage levels, which are to be reproduced as

separate grids in the system It is even possible to allocate different grids (and therefore also different distributors) to points of delivery for different voltage levels when a connection object (one postal address) has a number of points of delivery.

Recording grid hierarchies You can record grid hierarchies in the system by specifying a higher-level grid for a grid. These hierarchies can be evaluated when schedules are created in order to create overall schedules for the different grids.



HigherHigherHigherHigher----level gridlevel gridlevel gridlevel grid

001

003

004

002

005006

Grid hierarchyGrid hierarchyGrid hierarchyGrid hierarchy

Regional Regional Regional Regional structurestructurestructurestructure

Voltage levelVoltage levelVoltage levelVoltage level(e.g. 20 kV)(e.g. 20 kV)(e.g. 20 kV)(e.g. 20 kV)

NetCo

DistributorDistributorDistributorDistributor

Grid

Distribution grid across several control areas If a distribution grid extends across several control areas managed by different control area operators, each part of a distribution grid that is located in the area covered by a control area must be managed as a separate grid in the system for settlement purposes.



Regional supplier

Control area operator

Municipal utility company Grid 1 Grid 2

Municipal utility company

Control area operator

Regional supplier

Municipalutility company

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 a distributor. The distributor is a service provider who is assigned a service type belonging to the service category Distribution. It is also possible to allocate a grid to several voltage levels.

3.3.2 Data Model



Serviceprovider

ServiceNon-

billable


DeviceRegister

Premise

Contractbillableservice

Contractaccount

Businesspartner

Connectionobject

Regionalstructure

Grid

Default valueD

istri

b uto

r

Deregulated

Technical

Serv

ice

cat.

Dis

tribu

tion

The following relationships are possible between points of delivery and grids: A grid can be allocated to a point of delivery as an attribute. These points of delivery normally

correspond to physical devices. This means it is possible to perform separate settlements for individual grids in EDM.

The allocation of a virtual point of delivery to a grid enables you to store settlement results for each grid in Energy Data Management. You can make this allocation in the Utilities Industry menu under Intercompany Data Exchange Grid Allocate Point of Delivery to Grid. The Header tab contains a Grid tab. If you want to delimit the validity period of the grid allocation, this is only possible here.

Caution This maintenance authorization should only be assigned to a small number of users, since it allows changes to sensitive data.

3.3.3 Maintenance To allocate a grid to a point of delivery, enter a grid in the group frame Point of Delivery when you create the installation.



Note If you do not specify a point of delivery ID, you can specify a grid in the installation (optional). However, if you do enter a point of delivery ID, you must specify a grid. The grid is a new entity introduced in Release 4.63, which means that if you upgrade your system from 4.62, the point of delivery is not directly allocated a grid. This is the only case in which an installation with a point of delivery ID is not allocated a grid. The functions that require the grid (definition of default values for services, for example) automatically search the regional structure if no grid is found for the point of delivery. In EDM, the settlement settings determine whether or not you need to specify a grid. If you do



and you are upgrading from 4.62 to 4.63, you must ensure that all points of delivery are allocated grids.

If a grid is not specified in the installation, the system attempts to determine a default value from the regional structure. For this reason, you should have entered a grid for the voltage level beforehand in the Grids group frame for the city or street, which you can access in the Utilities Industry menu under Regional Structure Postal City or Street. If you do not enter a voltage level, the grid is valid for all voltage levels. The system compares the voltage level entered in the installation with that in the regional structure and determines the appropriate grid. When you create installations without dialog (for example directly, using automation data, or with the master data generator), you can enter values for the grid, like all other installation data, using auto data.

Note Since some grid data can only be maintained in Customizing, the processing functions available in a production system are limited, particularly when adding new grids. For this reason, it is planned that grid maintenance be moved from Customizing to the application.

3.4 Services

3.4.1 Description A service is performed for a point of delivery. Services are subdivided into billable services and non-billable services (NB services). All of a companys own or third-party services that are billed and/or invoiced are recorded in IS-U as a contract. This contract is also referred to as a billable service. All other services are non-billable services (NB services). The most important characteristics of services are the following: Service type

You can define service types as you wish. You must allocate them to one of the standard SAP service categories in Customizing. You can allocate the Others service category to all service types that do not correspond to any of the standard service categories. If you want to use a service type based on the Others service category internally in a program, you must modify the templates according to your requirements.

Service provider For further information on the service provider, see unit 3.5 (Service Provider).

Validity period of a service The validity period of a billable service (contract) is determined from the move-in and move-out date and the service is recorded in the allocated installation.

The NB services that can be created during move-in or during service maintenance in the point of delivery transaction are determined by a proposal mechanism, which is described in unit 5 (Dynamic Business Processes). You maintain default values for NB services in Customizing. A distinction is made here between optional and non-optional services.


Cookbook Intercompany Data Exchange Optional services are not created automatically during move-in. They are proposed in the move-in transaction or during maintenance of point of delivery services in the point of delivery transaction and the user decides at this point whether or not the services are to be created. Non-optional services are created automatically during move-in.

3.4.2 Data Model NB services are recorded as a separate entity for the point of delivery.

Serviceprovider

ServiceNon-

billable


Contract Billableservice

Contractaccount

Businesspartner

#

3.4.3 Maintenance You can change NB services manually using the transaction Change Point of Delivery. To do this, go to the Utilities Industry menu and choose Technical Master Data Point of Delivery Change. Once you have selected the point of delivery, choose the Point of Delivery Service tab page. You can now change certain attributes of the services. The system proposes all the optional services that can be created automatically when you save. If you do not want to create one of these optional services, you must clear the entry field Service Provider for that service. A colored symbol indicates the status of each service or service proposal:

A service exists or will be created when you save. An optional service exists. You can remove it by clearing the Service Provider field and saving. An optional service is proposed. It will be created when you save if the Service Provider field

contains an entry. If you clear the field, the service will not be created.



There is a service that is in conflict with the current service proposals. It either no longer exists in Customizing or is not proposed in the current situation for a certain reason, for example because a contract (billable service) already exists for the same service type.

Notes The date with which the point of delivery to be changed was selected is used as the start date for the optional services created in the point of delivery transaction. The transaction Move-In Change does not propose new services. If you want to repeat the proposal procedure for services after move-in, you must use the transaction Point of Delivery Change. At present, the point of delivery transaction only works with the proposal procedure based on the service area. The service area is determined from the grid allocated to the point of delivery (see section 5.1.1.2).

Caution The changes made to the services using the Change Point of Delivery transaction are isolated changes for which a general validation does not take place. This means the user making the change is responsible for informing any persons or companies affected about the changes. For this reason, you should only make corrections in exceptional cases and not use this transaction to map processes such as supplier change manually.


Cookbook Intercompany Data Exchange Unit 5 (Dynamic Business Processes) contains information on how a service change normally takes place and how the system automatically determines which services are created for a customer.

3.5 Service Provider

3.5.1 Description The service provider has two main functions in IDE: 1. They represent the central communication object.

You define when and to whom which type of information is sent in the Customizing settings for Intercompany Data Exchange under Communication Control Define Function Modules for Processing Events and Define Communication Based on Service Providers. If communication occurs using IDocs, the logical transmission address of the recipient is determined from the relevant Customizing settings. Before you can do this, you must maintain partner profiles for partner type SP (IS-U Service Provider) under Tools Business Communication IDoc Basis IDoc Partner Profile. For further details, see unit 12.5 (IDoc).

Note Do not use purely numeric values as keys for service providers, since this leads to problems when maintaining partner profiles. If you allocate a service provider to a business partner, you can use the business partner functions for non-electronic communication (for example, for address management, contact persons, and telephone numbers).

3. The service provider plays an important role in defining the deregulation scenario for a point of

delivery. A service provider can be allocated to a variety of objects in IS-U, such as services (billable and non-billable) and installations. For more details, see unit 3.6 (Deregulation Data in IS-U Master Data).

You can allocate one service type to a service provider. If a company provides several service types, you must define a corresponding number of different service providers in Customizing. These can then have the same external number and the same business partner allocation.



3.5.2 Data Model Data storage for service providers is divided into two stages: The service provider is defined in Customizing for Intercompany Data Exchange under Service

Provider Define Service Providers. Allocation of a business partner, vendor and G/L account can only take place in the production

system, since the relevant master data is only available at this point.

NB service

ESERVPROVCustomizing

Contract

ESERVPROVPTransaction

data

VendorG/Laccount

Businesspartner

Service provider Grid

InstallationFurther

Customizing

3.5.3 Maintenance Other important characteristics of a service provider in Customizing include the following: Company code If a service provider acts as billing agent for another service provider, the billing agent must create a contract for the other service provider so that the service can be settled separately. To keep the two separate for accounting purposes, you must use a different company code. If you specify the company code in the data on the service provider, the system can enter this company code as a default value during move-in. Service providers in your own system All of your companys own service providers that are managed in one client must be marked as service providers belonging to your own system; that is to say, you must flag the SP field (service provider managed in own system) for these service providers.


Cookbook Intercompany Data Exchange This information is vital for determining which service provider is the sender and which is the recipient in communication control. For further information, please see unit 6 (Communication Control). The following example demonstrates how service providers are maintained from the suppliers (SUPP) point of view. All the distributors in whose grid areas customers are supplied are maintained in supplier SUPPs system. The distributors are allocated the same company code, since the supplier is sole provider. Since schedules are to be switched, supplier SUPP has specified settlement coordinators SETTL1 and SETTL2, in whose control areas he supplies customers.

To access the maintenance and display functions for business partners, vendors and G/L accounts choose: Service Provider Create/Change or Display Partner Data for Service Provider. For payment in some deregulation scenarios, individual receivables are aggregated for each customer according to service provider. Both the vendor and the G/L account must be defined for the service provider so that the necessary postings in Accounts Payable Accounting (FI-AP) can be made using a report. This is illustrated in a continuation of the above example. The only potential vendors are the other distributors, since inbound grid usage bills are to be transferred aggregated to FI-AP. The settlement coordinators only need to know which business partner is allocated.



3.6 Deregulation Data in IS-U Master Data This unit describes the fields in installation and service master data that influence determination of the deregulation scenario, as well as the various ways in which these fields can be combined.

3.6.1 Relevant Fields in the Installation Service type: The service type is the central field for controlling deregulation data in the installation and the contract.

When you enter a service type in an installation, this installation is in a deregulated environment by definition. During move-in, the technical master data (installation) is linked with the business master data (contract). The service type in the installation tells the system that entries are also required for the deregulation fields in the contract.

Caution Once the installation has been linked with the contract by move-in, you cannot make any further changes to the service type in the installation. For this reason, you must ensure that the Service Type field in the installation contains the correct entry during data transfer.

Billing service provider: This service provider, who bills the installation, is part of the installation history and determines who bills the corresponding contract. If you specify a service type in the installation, you must specify a billing service provider. You enter the billing service provider in the Time-Dependent Data group frame.

Historical changes are analyzed in such a way that the service provider valid on a key date is always determined. For example, a bill is sent at the end of the settlement period. This means changes within the billing period do not lead to proration.



3.6.2 Relevant Fields in the Contract

Service provider: The service provider in the contract determines who is the owner of the contract or billable service. The technical master data (installation) is linked with the business master data (contract) during move-in. The service type in the installation tells the system that entries are also required for the deregulation fields in the contract. This means that the Service Provider field in the contract is a required field during move-in if the Service Type field in the installation contains an entry.

Caution It is not possible to change the service provider in the contract at a later stage. If you need to make a change of this kind, you must cancel and repeat the move-in.

Invoicing service provider: The service provider you enter here carries out invoicing for a settlement performed for this contract, and therefore acts as invoicing party for the customer. The invoicing service provider is therefore also responsible for collection for these bills. The field is a required field if the contract is allocated a service provider. If you enter an invoicing service provider who is not marked as the service provider from your own system (that is to say, for whom the field Service provider managed in own system is not flagged) in the Customizing settings for Intercompany Data Exchange under Service Provider Define Service Provider, this service provider is usually a billing consolidator. In this case, you expect payment of the invoiced amount from the billing consolidator. Payment class: The payment class is an important instrument for account-based processing in the deregulated market. You must always specify a payment class in the contract if the service provider in the contract differs from the invoicing service provider and the two are managed in different systems.

ContractServ. prov.: SUPPInvoicing: GRID01

Pyt class: ADV



Note If both service providers are marked as service providers managed in your own system in the Customizing settings for Intercompany Data Exchange under Service Provider Define Service Provider, you do not need to enter a payment class, since in this case account-based processing does not take place.

The system uses the settings you made beforehand in Customizing for Intercompany Data Exchange under Service Provider Payment Control Allocate Payment Process and Payment Frequency to Service Provider to determine the payment process and payment frequency from the combination of payment class and service provider. This data maps contractual agreements with another service provider who is not managed in your own system. You can use the payment class to distinguish between these agreements for each service provider according to criteria of your choice (for example, to define different payment processes and frequencies for different customer groups). The system provides checks that ensure that the payment class (and therefore the payment process) is used plausibly. Only the payment process is relevant for further analysis in this unit. The following payment processes are provided by SAP: Sole provider Customer payment Advance payment Customer payment and advance payment refer to a billing agent scenario. The payment process has the following functions: Determines the correct procedure in the suppliers system for inbound bills from the distributor Indicates whether the supplier is acting as sole provider or billing agent, so that the bill is

processed correctly Distinguishes advance payment from customer payment in the billing agent scenario Consequently, the payment process provides information on the current scenario. The following screenshot shows the system settings from a suppliers point of view. The allocation of the payment process and frequency can be found in Customizing for Intercompany Data Exchange under Service Provider Payment Control Allocate Payment Process and Payment Frequency to Service Provider.



The supplier has come to an agreement with distributor GRID01 involving customer payment (and therefore a billing agent scenario) as well as a sole provider scenario. The distributor has come to an agreement with distributor GRID02 that involves advance payment (and therefore a billing agent scenario only) that differs according to payment frequency. For example, different conditions could apply to residential customers than to nonresidential customers. This Customizing activity alone does not tell us whether the supplier or the distributor acts as billing agent or sole provider. This can only be determined from the data environment of the master data.

Note You need both the standard Customizing settings and the deregulation data in the master data to determine the scenario in question.


Cookbook Intercompany Data Exchange The following case scenarios illustrate what information the payment process provides: 1. Invoicing for a different service provider (suppliers perspective)

Example The supplier receives the bill from the distributor and invoices the bill as billing agent

The supplier has created a grid usage contract in which distributor GRID01 is entered as the service provider and supplier SUPP as the invoicing service provider.

PoD55684

Contractaccount

Energy supplycontract

Serv. prov.: SUPPInvoicing: SUPP

Pyt class:

Grid usagecontract

Serv. prov.: GRID01Invoicing: SUPPPyt class: CUST

InstallationServ. type: SUPP

Billing: SUPP

InstallationServ. type: GRIDBilling: GRID01

SupplierSUPP

The payment process is determined from the combination of the payment class and service provider GRID01. Further processing of the incoming bill (that is to say, when and how payment is made) is determined from the payment process.



2. Billing by another service provider (distributors perspective)

... Example The distributor sends the bill to the supplier, who invoices the bill as billing agent.

The distributor has created a grid usage contract in which he himself is entered as the service provider, and supplier SUPP is entered as the invoicing service provider.

PoD55684

Contractaccount

ServiceServ. type: SUPPServ. prov.: SUPP

Pyt class:

ContractServ. prov.: GRID01

Invoicing: SUPPPyt class: CUST


DistributorGRID01

The payment process is determined from the combination of the payment class and the invoicing service provider (SUPP).

Note Unlike the first example, here the invoicing service provider is relevant in determining the payment process.

In this case, the payment process is used simply to provide the distributor with information on the due date of the bill and on whether or not it is possible to monitor payments.

3.6.3 Relevant Fields in NB Services Service provider: The service provider in the service is only important in determining a deregulation scenario in so far as they can be a service provider managed in your own system. Otherwise, the service provider has the task of describing the communication partner (as is also the case in the contract).


Cookbook Intercompany Data Exchange Payment class: Similarly to the payment class in the contract, the combination of the service provider and payment class is used to determine the payment process. You only need to specify a payment class when dealing with a sole provider scenario. A distinction must be made between the following two cases: 1. Invoicing of an NB service by a different service provider (distributors perspective)

Example The distributor provides the supplier with the meter reading results and the supplier then carries out billing and invoicing for itself and for the distributor.

PoD55684

ContractContractContractContractaccountaccountaccountaccount

PoD55684


Pyt class:

InstallationServ. type: GRID

Billing: SUPP

ContractServ. prov.: SUPPInvoicing: SUPP

Pyt class:




Billing: SUPP


Billing: SUPP

DistributorGRID01

SupplierSUPP

This case has not occurred in any market to date. You should record an NB service of your own, for which a customer is billed as a contract in your own system, even if billing and invoicing are carried out by another service provider. You have a contractual obligation at least to your customer. A contract is also required in the data model in order to retain the link between the customer and the point of delivery and related services.



2. Supplier acts as sole provider for the distributor (suppliers perspective)

Example Incoming bills from the distributor are transferred aggregated to Accounts Payable Accounting (FI-AP) and cleared there.

PoD55684

Contractaccount

PoD55684

Contractaccount


Invoicing: SUPPPyt class: SOLE


Pyt class:



Pyt class:

ServiceServ. type: GRID

Serv. prov.: GRID01Pyt class: SOLE


Billing: SUPP

DistributorGRID01

SupplierSUPP

This example demonstrates that the use of the payment class in the NB service is restricted to sole provider scenarios. In all other cases, the payment class must be left blank in the service. Other payment processes lead to processes being cancelled.

3.6.4 Possible Deregulation Scenarios The combination of the fields described above in the installation, contract and service determines the deregulation scenario. If only two service providers (distributor and supplier) exist for a point of delivery, the number of possible combinations is relatively small. If more service types are used, and therefore more corresponding service providers, the number of deregulation scenarios increases. For this reason, the simplest strategy is to analyze a pair of service providers (where one is always your own company) and initially to analyze the relationship between these two service providers. This strategy is also used in scenario determination. From this point of view, only the analysis of supplier and distributor is generally valid. For an overview of known deregulation scenarios at this time, see the appendix. The following examples provide a more detailed description of the four most common scenarios. The examples focus primarily on the technical background, that is, the data model in IS-U and the fields that contain entries. Unit 5 (Dynamic Business Processes) describes the mechanisms that can be used to create these data constructs manually and automatically.



3.6.4.1 Example 1: Supplier as Billing Agent and Rate Ready The data model is as follows:

PoD55684

Contractaccount

PoD55684

Contractaccount




Pyt class:


Billing: SUPP


Pyt class:




Billing: SUPP


Billing: SUPP

DistributorGRID01

SupplierSUPP

Suppliers perspective: Since the supplier bills for itself and for the distributor and invoices the distributors bill, two different company codes and therefore two contracts are required. The main reason for using two company codes is value-added tax, which must be recorded separately. The fact that the billing service provider (SUPP) and invoicing service provider (SUPP) are the same in the grid usage contract but are not the same as the service provider in the contract (GRID01) indicates that this is a rate ready process. The payment process Customer Payment is determined by combining the service provider GRID01 and the payment class CUST. Distributors perspective: Only one grid usage contract is required in the distributors system. Even if the distributor does not perform billing itself, as in this case, the data model requires that the grid usage contract with the customer must exist. Before consumption data can be sent, this contract must be billed. However, billing must be carried out without creating invoice lines relevant for posting or printing. A payment class is specified in the contract because a different service provider, who is managed in a different system, invoices the billable service grid usage (see section Payment Class in unit 3.6.2 Relevant Fields in the Contract). The payment class must be linked to a payment process that is relevant for billing agents, that is, customer payment or advance payment.


Cookbook Intercompany Data Exchange Information on electric power supply is recorded in the distributors system as an NB service with the relevant supplier as the service provider. A payment class is not specified in the NB service since this is a billing agent scenario and not a sole provider scenario (see section Payment Class in unit 3.6.3 Relevant Fields in NB Services). The fact that the billing service provider (SUPP) and invoicing service provider (SUPP) are the same in the grid usage contract but do not correspond to the service provider in the contract (GRID01) indicates that this is a rate ready process. The payment process customer payment is determined from the combination of invoicing service provider SUPP and the payment class CUST. In this case, the payment process is purely for information purposes. For various reasons, a company might decide when implementing IDE that they always want to manage two contracts in the distributors system. This might appear make sense if the market allows for different scenarios, which would allow the company to choose, for example, whether the distributor or the supplier acts as billing agent. This would mean there would always be two contracts in the system. SAP advises you not to use a dual contract model for the following reasons: 1. In the above scenario, the distributor would have to create a dummy energy supply contract in

their system. This contract would have to be processed in billing and invoicing with a dummy rate, although it has no actual function. If the supplier changed, move-in and move-out would also have to be performed.

2. In future, both contracts and NB services will be visible under Services in the Customer Interaction Center.



3.6.4.2 Example 2: Distributor as Billing Agent and Bill Ready The data model is as follows:

PoD55684

Contractaccount


Pyt class: ADV


Serv. prov.: GRID01Pyt class:


Billing: SUPP

PoD55684

Contractaccount


Pyt class: ADV

ContractServ. prov.: GRID01Invoicing: GRID01

Pyt class:


Billing: SUPP


DistributorGRID01

SupplierSUPP

Suppliers perspective: The suppliers system only requires an energy supply contract, which the supplier bills itself. A payment class is specified in the contract because a different service provider, who is managed in a separate system, invoices the billable service energy supply (see section Payment Class in unit 3.6.2 Relevant Fields in the Contract). The payment class must be linked to a payment process that is relevant for billing agents, that is, customer payment or advance payment. Data on grid usage is recorded in the suppliers system as an NB service with the relevant distributor as the service provider. A payment class is not specified in the NB service, since this is a billing agent scenario and not a sole provider scenario (see section Payment Class in unit 3.6.3 Relevant Fields in NB Services). The fact that the billing service provider (SUPP) is the same as the service provider in the contract (SUPP) but the billing service provider (SUPP) and invoicing service provider (GRID01) are not the same indicates that this is a bill ready process. The payment process advance payment is determined in the suppliers system from the combination of the invoicing service provider GRID01 and the payment class ADV. In this case, the payment process is purely for information purposes.


Cookbook Intercompany Data Exchange Distributors perspective: Since the distributor also invoices the suppliers bill, two different company codes, and therefore two contracts are required. The principal reason for using two company codes is value-added tax, which must be managed separately. The fact that the billing service provider (SUPP) is the same as the service provider in the contract (SUPP) but the billing service provider (SUPP) and invoicing service provider (GRID01) are not the same indicates that this is a bill ready process. The payment process advance payment is determined in the suppliers system from the combination of the invoicing service provider GRID01 and the payment class ADV.

3.6.4.3 Example 3: Supplier as Sole Provider The data model is as follows:

PoD55684

Contractaccount

PoD55684

Contractaccount


Invoicing: SUPPPyt class: SOLE


Pyt class:



Pyt class:


Serv. prov.: GRID01Pyt class: SOLE


Billing: SUPP

DistributorGRID01

SupplierSUPP

A single contract model is possible in both systems in a sole provider scenario. Suppliers perspective: The suppliers system only requires one energy supply contract, which the supplier bills and invoices itself. A payment class is not specified in the contract, since the service provider for the billable service energy supply is the same as the service provider who invoices this contract and the two are managed in the same system (see section Payment Class in unit 3.6.2 Relevant Fields in the Contract).


Cookbook Intercompany Data Exchange Grid usage data is recorded in the suppliers system as an NB service with the relevant distributor as the service provider. A payment class is specified in the NB service, since this is a sole provider scenario (see section Payment Class in unit 3.6.3 Relevant Fields in NB Services). The distributor executes billing for grid usage. The distributor bills the supplier for grid usage costs. Incoming bills from the distributor in the suppliers system are transferred aggregated to Accounts Payable Accounting (FI-AP), where they are cleared. The supplier pays the distributor the grid usage charges without invoicing them in FI-CA himself. From the customers perspective, the supplier acts alone as sole provider for both services (grid usage and energy supply). The supplier does not list the grid usage costs separately on the bill to the customer but instead defines their own rate for all services. The payment method sole provider is determined in the suppliers system from the combination of the service provider GRID01 and the payment class SOLE. Distributors perspective: The distributors system only requires a grid usage contract, which the distributor bills itself. A payment class is specified in the contract, since a different service provider, who is managed in a different system, invoices the billable service grid usage (see section Payment Class in unit 3.6.2 Relevant Fields in the Contract). Electric power supply data is stored in the distributors system as an NB service with the corresponding supplier as service provider. A payment class is not specified in the NB service, since this NB service is purely for information purposes.



3.6.4.4 Example 4: Dual Billing The data model is as follows:

PoD55684

Contractaccount

PoD55684

Contractaccount

ContractServ. prov.: GRID01Invoicing: GRID01

Pyt class:


Pyt class:



Pyt class:


Serv. prov.: GRID01Pyt class:


Billing: SUPP

DistributorGRID01

SupplierSUPP

In addition to the contract for billing and invoicing of their own service, both the distributor and the supplier store data on the other service as an NB service in their systems. This is necessary for communication with the other service provider (for example, sending meter reading results, changing customer data, and reporting loss of customers). The data model is almost identical to that of the sole provider, with the following exceptions: Distributors perspective: The distributor invoices the billable service GRID itself. No payment class is specified in the contract in the distributors system. Suppliers perspective: In contrast to the sole provider scenario, the payment class is not specified in this case in the NB service GRID in the suppliers system.



4 Static Business Processes Static business processes refer to periodically recurring business transactions that require a certain amount of data (typically, a large amount) to be exchanged between service providers. Typical examples are meter reading, billing, and payment transactions. Provided that data is exchanged in conjunction with periodic meter reading and periodic billing, we must regard the entire process as a higher-level process. This will be explained in more detail in the final section of this unit using typical deregulation scenarios as examples. It is assumed that the supplier and the distributor are different companies and are managed in separate systems. In the event that the supplier and the distributor for one point of delivery are managed in the same system, refer to unit 9 (Supplier and Distributor in One System). You may also notice that the names of intermediate documents (IDocs), function modules and other modules that contain template character are not mentioned in the following sections. This is because different templates that have been adapted for different markets can be used for the same function. You can find all possible template names in the appendix or in the relevant standard entry tables in Customizing.

4.1 Sending and Receiving Consumption Data Consumption values calculated from meter readings (or as an exception, from replacement values) are the basis for billing for grid usage and for energy supply. Demand values can of course also play a part. In this unit, however, it is not necessary to differentiate between the two. Sending and receiving interval meter data, which enables the supplier to offer the customer Real-Time-Pricing (RTP) billing, for example, is not dealt with here. For more information, read unit 7 (Integration of EDM Functions). On request from a new supplier, historical consumption data can be sent. Templates for receiving historical consumption data are not available (this is usually part of the supplier change process).

4.1.1 Prerequisites Meter reading is usually the responsibility of the distributor. In almost all deregulated markets, the distributor is obliged to provide the supplier with both meter reading data and consumption data. The templates provided by SAP work on the assumption that the supplier carries out billing based on consumption values from the distributor and that meter readings are required (on the bill, for example). It is also assumed that the supplier does not run the complete IS-U-Device Management (IS-U-DM) component, but works using device information records. It is of course possible that the supplier works using meter readings and calculates consumption internally. However, this means that the supplier would have to have the complete Device Management component in the system, since detailed information such as register factors and billing factors is required to determine consumption (more information is needed for Gas depending on the procedures you use).



4.1.2 Outbound The following diagram shows the process of sending consumption data according to the distributor:

Entermeter reading

results

Start billingfor

grid usage

Selectaffected

billing line items

Create IDoc

End billingfor

grid usage

EventBILLCREATE

Process modulefor preparation

of data from billing line items

The process of sending consumption data starts in billing, as this is the only time that the exact consumption value is available. The system obtains the information on consumption values and meter reading results from the individual billing line items in the billing document. You can define billing line item types in Customizing under Intercompany Data Exchange Communication Control Communication Control of Outbound Messages Define Line Item Types Relevant to Communication. You have to set up the rates and schemas accordingly. They must contain variants that write billing line items using the defined line item types. This means that info lines are generally written from all variants to consumption billing. A typical example is the billing line item IQUANT in the standard system that not only provides consumption data but also provides meter reading data when it is available. The meter reading data contains all meter readings carried out within the billing period. It is, therefore, possible to send all previous meter readings up to the meter reading that was last billed (old register status). This also includes device replacement. SAP recommends that you send consumption data irrespective of the actual billing criteria. This means that in a (new) rate, you can include all variants containing company-specific line item types that were purely intended for sending data.