You are on page 1of 153

.....

..... Page 1 of 153


Cook book Cook book Cook book Cook book
I nt er c ompany Dat a Ex c hange I nt er c ompany Dat a Ex c hange I nt er c ompany Dat a Ex c hange I nt er c ompany Dat a Ex c hange

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.






SAP AG Cookbook IDE Page 3 of 153

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

SAP AG Cookbook IDE Page 4 of 153

Cookbook
Intercompany Data Exchange


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

SAP AG Cookbook IDE Page 5 of 153

Cookbook
Intercompany Data Exchange


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

SAP AG Cookbook IDE Page 6 of 153

Cookbook
Intercompany Data Exchange


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


SAP AG Cookbook IDE Page 7 of 153

Cookbook
Intercompany Data Exchange


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.

SAP AG Cookbook IDE Page 8 of 153

Cookbook
Intercompany Data Exchange



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.

SAP AG Cookbook IDE Page 9 of 153

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
















SAP AG Cookbook IDE Page 10 of 153

Cookbook
Intercompany Data Exchange


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
Communication
control
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.

SAP AG Cookbook IDE Page 11 of 153

Cookbook
Intercompany Data Exchange


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
MSCONS
1
and DELFOR
2
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.

SAP AG Cookbook IDE Page 12 of 153

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,
EDIFACT
3
, 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 shapes
4
or schedules according to different settlement
procedures
5
.

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.

SAP AG Cookbook IDE Page 13 of 153

Cookbook
Intercompany Data Exchange


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

SAP AG Cookbook IDE Page 14 of 153

Cookbook
Intercompany Data Exchange


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.

Ser vi c e
pr ovi der
Ser vi c e
not
bi l l abl e
Poi nt of
del i ver y
I nst al l at i on
Devi c e Regi st er
Pr emi se
Cont r ac t
bi l l abl e
ser vi c e
Cont r ac t
ac c ount
Busi ness
par t ner
Connec t i on
obj ec t
Regi onal
st r uc t ur e
Gr i d
Default value
D
i
s
t
r
i
b
u
t
o
r
Deregulated
Technical
S
e
r
v
i
c
e

c
a
t
.
D
i
s
t
r
i
b
u
t
i
o
n


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.

SAP AG Cookbook IDE Page 15 of 153

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

Ser vi c e
Non-
bi l l abl e
Poi nt of
del i ver y
I nst al l at i on
Regi st er
Deregulation role
T
e
c
h
n
i
c
a
l
r
o
l
e
Poi nt of
del i ver y I D
Example: by metering code
DE 4711 69190 1234567890
Gr i d


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

SAP AG Cookbook IDE Page 16 of 153

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.


SAP AG Cookbook IDE Page 17 of 153

Cookbook
Intercompany Data Exchange


Hi gher Hi gher Hi gher Hi gher - -- -l evel gr i d l evel gr i d l evel gr i d l evel gr i d
001
003
004
002
005
006
Gr i d hi er ar c hy Gr i d hi er ar c hy Gr i d hi er ar c hy Gr i d hi er ar c hy
Regi onal Regi onal Regi onal Regi onal st r uc t ur e st r uc t ur e st r uc t ur e st r uc t ur e
Vol t age l evel Vol t age l evel Vol t age l evel Vol t age l evel
(e.g. 20 k V) (e.g. 20 k V) (e.g. 20 k V) (e.g. 20 k V)
NetCo
Di st r i but or Di st r i but or Di st r i but or Di st r i but or
Gr i d


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.


SAP AG Cookbook IDE Page 18 of 153

Cookbook
Intercompany Data Exchange


Regi onal suppl i er
Cont r ol ar ea oper at or
Muni c i pal
ut i l i t y c ompany
Gr i d 1 Gr i d 2
Muni c i pal
ut i l i t y c ompany
Cont r ol ar ea oper at or
Regi onal suppl i er
Muni c i pal
ut i l i t y c ompany


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


SAP AG Cookbook IDE Page 19 of 153

Cookbook
Intercompany Data Exchange


Ser vi c e
pr ovi der
Ser vi c e
Non-
bi l l abl e
Poi nt of
del i ver y
I nst al l at i on
Devi c e Regi st er
Pr emi se
Cont r ac t
bi l l abl e
ser vi c e
Cont r ac t
ac c ount
Busi ness
par t ner
Connec t i on
obj ec t
Regi onal
st r uc t ur e
Gri d
Default value
D
i
s
t
r
i
b
u
t
o
r
Deregulated
Technical
S
e
r
v
i
c
e

c
a
t
.

D
i
s
t
r
i
b
u
t
i
o
n


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.



SAP AG Cookbook IDE Page 20 of 153

Cookbook
Intercompany Data Exchange





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

SAP AG Cookbook IDE Page 21 of 153

Cookbook
Intercompany Data Exchange


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.

SAP AG Cookbook IDE Page 22 of 153

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.

Ser vi c e
pr ovi der
Ser vi c e
Non-
bi l l abl e
Poi nt of
del i ver y
I nst al l at i on
Cont r ac t
Bi l l abl e
ser vi c e
Cont r ac t
ac c ount
Busi ness
par t ner
#

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.

SAP AG Cookbook IDE Page 23 of 153

Cookbook
Intercompany Data Exchange



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.


SAP AG Cookbook IDE Page 24 of 153

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.

SAP AG Cookbook IDE Page 25 of 153

Cookbook
Intercompany Data Exchange



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 ser vi c e
ESERVPROV
Cust omi zi ng
Cont r ac t
ESERVPROVP
Tr ansac t i on
dat a
Vendor
G/L
ac c ount
Busi ness
par t ner
Ser vi c e pr ovi der
Gr i d
I nst al l at i on
Fur t her
Cust omi zi ng

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.

SAP AG Cookbook IDE Page 26 of 153

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.



SAP AG Cookbook IDE Page 27 of 153

Cookbook
Intercompany Data Exchange






SAP AG Cookbook IDE Page 28 of 153

Cookbook
Intercompany Data Exchange


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.

SAP AG Cookbook IDE Page 29 of 153

Cookbook
Intercompany Data Exchange



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.

Cont ract
Serv. prov.: SUPP
Invoicing: GRID01
Pyt class: ADV


SAP AG Cookbook IDE Page 30 of 153

Cookbook
Intercompany Data Exchange



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.


SAP AG Cookbook IDE Page 31 of 153

Cookbook
Intercompany Data Exchange




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.


SAP AG Cookbook IDE Page 32 of 153

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.

PoD
55684
Cont r ac t
ac c ount
Ener gy suppl y
c ont r ac t
Serv. prov.: SUPP
Invoicing: SUPP
Pyt class:
Gr i d usage
c ont r ac t
Serv. prov.: GRID01
Invoicing: SUPP
Pyt class: CUST
I nst al l at i on
Serv. type: SUPP
Billing: SUPP
I nst al l at i on
Serv. type: GRID
Billing: GRID01
Suppl i er
SUPP


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.


SAP AG Cookbook IDE Page 33 of 153

Cookbook
Intercompany Data Exchange



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.

PoD
55684
Contract
account
Service
Serv. type: SUPP
Serv. prov.: SUPP
Pyt class:
Contract
Serv. prov.: GRID01
Invoicing: SUPP
Pyt class: CUST
Installation
Serv. type: GRID
Billing: GRID01
Di st r i but or
GRI D01



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


SAP AG Cookbook IDE Page 34 of 153

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.

PoD
55684
Cont r ac t Cont r ac t Cont r ac t Cont r ac t
ac count ac count ac count ac count
PoD
55684
Service
Serv. type: SUPP
Serv. prov.: SUPP
Pyt class:
Installation
Serv. type: GRID
Billing: SUPP
Contract
Serv. prov.: SUPP
Invoicing: SUPP
Pyt class:
Contract
Serv. prov.: GRID01
Invoicing: SUPP
Pyt class: CUST
Installation
Serv. type: SUPP
Billing: SUPP
Installation
Serv. type: GRID
Billing: SUPP
Di st r i but or
GRI D01
Suppl i er
SUPP


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.

SAP AG Cookbook IDE Page 35 of 153

Cookbook
Intercompany Data Exchange



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.

PoD
55684
Contract
account
PoD
55684
Contract
account
Contract
Serv. prov.: GRID01
Invoicing: SUPP
Pyt class: SOLE
Service
Serv. type: SUPP
Serv. prov.: SUPP
Pyt class:
Installation
Serv. type: GRID
Billing: GRID01
Contract
Serv. prov.: SUPP
Invoicing: SUPP
Pyt class:
Service
Serv. type: GRID
Serv. prov.: GRID01
Pyt class: SOLE
Installation
Serv. type: SUPP
Billing: SUPP
Di st r i but or
GRI D01
Suppl i er
SUPP


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.


SAP AG Cookbook IDE Page 36 of 153

Cookbook
Intercompany Data Exchange


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

PoD
55684
Contract
account
PoD
55684
Contract
account
Contract
Serv. prov.: GRID01
Invoicing: SUPP
Pyt class: CUST
Service
Serv. type: SUPP
Serv. prov.: SUPP
Pyt class:
Installation
Serv. type: GRID
Billing: SUPP
Contract
Serv. prov.: SUPP
Invoicing: SUPP
Pyt class:
Contract
Serv. prov.: GRID01
Invoicing: SUPP
Pyt class: CUST
Installation
Serv. type: SUPP
Billing: SUPP
Installation
Serv. type: GRID
Billing: SUPP
Di st r i but or
GRI D01
Suppl i er
SUPP


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.

SAP AG Cookbook IDE Page 37 of 153

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.

SAP AG Cookbook IDE Page 38 of 153

Cookbook
Intercompany Data Exchange



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

PoD
55684
Contract
account
Contract
Serv. prov.: SUPP
Invoicing: GRID01
Pyt class: ADV
Service
Serv. type: GRID
Serv. prov.: GRID01
Pyt class:
Installation
Serv. type: SUPP
Billing: SUPP
PoD
55684
Contract
account
Contract
Serv. prov.: SUPP
Invoicing: GRID01
Pyt class: ADV
Contract
Serv. prov.: GRID01
Invoicing: GRID01
Pyt class:
Installation
Serv. type: SUPP
Billing: SUPP
Installation
Serv. type: GRID
Billing: GRID01
Di st r i but or
GRI D01
Suppl i er
SUPP


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.



SAP AG Cookbook IDE Page 39 of 153

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:

PoD
55684
Contract
account
PoD
55684
Contract
account
Contract
Serv. prov.: GRID01
Invoicing: SUPP
Pyt class: SOLE
Service
Serv. type: SUPP
Serv. prov.: SUPP
Pyt class:
Installation
Serv. type: GRID
Billing: GRID01
Contract
Serv. prov.: SUPP
Invoicing: SUPP
Pyt class:
Service
Serv. type: GRID
Serv. prov.: GRID01
Pyt class: SOLE
Installation
Serv. type: SUPP
Billing: SUPP
Di st r i but or
GRI D01
Suppl i er
SUPP


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

SAP AG Cookbook IDE Page 40 of 153

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.

SAP AG Cookbook IDE Page 41 of 153

Cookbook
Intercompany Data Exchange



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

PoD
55684
Contract
account
PoD
55684
Contract
account
Contract
Serv. prov.: GRID01
Invoicing: GRID01
Pyt class:
Service
Serv. type: SUPP
Serv. prov.: SUPP
Pyt class:
Installation
Serv. type: GRID
Billing: GRID01
Contract
Serv. prov.: SUPP
Invoicing: SUPP
Pyt class:
Service
Serv. type: GRID
Serv. prov.: GRID01
Pyt class:
Installation
Serv. type: SUPP
Billing: SUPP
Di st r i but or
GRI D01
Suppl i er
SUPP


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.








SAP AG Cookbook IDE Page 42 of 153

Cookbook
Intercompany Data Exchange


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

SAP AG Cookbook IDE Page 43 of 153

Cookbook
Intercompany Data Exchange



4.1.2 Outbound
The following diagram shows the process of sending consumption data according to the distributor:
Ent er
met er r eadi ng
r esul t s
St ar t bi l l i ng
f or
gr i d usage
Sel ec t
af f ec t ed
bi l l i ng l i ne i t ems
Cr eat e I Doc
End bi l l i ng
f or
gr i d usage
Event
BILLCREATE
Pr oc ess modul e
f or pr epar at i on
of dat a f r om
bi l l i ng l i ne i t ems

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. Variant QUANTI05 is usually used for this purpose.

When formatting the IDoc, it must be clear whether you are dealing with consumption or demand. To
make this type of distinction, irrespective of the name chosen for the line item type, you must allocate
the line item types in the Customizing table to an information type (in the consumption relevant

SAP AG Cookbook IDE Page 44 of 153

Cookbook
Intercompany Data Exchange


column). These information types are predefined and can be used for programming. The following
information types are currently defined:
PF for cosinus phi for demand. A variant program that calculates cosinus phi and writes an info
line in the billing document exists.
KH for active energy
K3 for reactive energy
K1 for demand
K2 for reactive power
BI for billed value
This is a purely informative value that includes the consumption value used by the distributor to
bill the customer (this can vary due to discounts, surcharges or other agreements with the
customer).

With the help of constants, you can immediately use these values for programming when completing
the IDocs.

Note
Sending cosinus phi, demand and inactive power is not currently integrated in the templates.
More constants are available in value range 0A to 0Z and can be used for company-specific
activities.

You can also maintain the IDoc unit of measurement in the Customizing table (field IDOC U/M). This
allows you to define measurement units appropriately in the IDoc rather than having to use the
standard SAP (and ISO) definitions.

All this is necessary so that the recipient has all the information required to allocate a consumption
value to a register. The requirements vary according to the market. The method described above for
information types is just one possibility. According to the definition of the EDIFACT message
MSCONS, for example, the so-called EDIS key figure is required. You can enter this value in the
Register code field during technical installation of a device (or it will be suggested in the register
group description). When preparing the MSCONS message, this information always has to come
from the installation structure (table ETDZ Technical Data for Installed Register).
You can also use more register-specific fields such as Register Identification to uniquely identify a
register. One restriction of using register-specific characteristics is that the consumption data is sent
for every billing (and therefore for every installation or point of delivery). This means that,
theoretically, registers with different characteristics (and therefore different register codes) can have
a common rate. This makes it impossible to uniquely allocate the consumption value allocated to a
rate to a register identification number. In practice, however, with a reasonable amount of
organization, you can easily avoid such a conflict.

SAP AG Cookbook IDE Page 45 of 153

Cookbook
Intercompany Data Exchange



4.1.3 Inbound
The following diagram shows the process of receiving consumption data according to the supplier:
I Doc wi t h
met er r eadi ng
and
c onsumpt i on
dat a
BAPI _MTRREADDOC_UPLOAD
Table
EMRDETAIL
Table
EABL
Ex ec ut e event
modul e i n I Doc
Event
USG_IN_ACT
St ar t
pr oc ess t empl at e
Fi nd MR or der s
Ex ec ut e devi c e
r epl ac ement
Wri t e c onsumpt i on i n
MR r esul t s f i l e
Wri t e det ai l ed i nf o
on met er readi ng
End
pr oc ess t empl at e


On receipt of an IDoc containing consumption data, a script with the following steps is executed in
the available templates:
Find the meter reading orders
In the templates it is assumed that the supplier has already created meter reading orders (or
billing orders) for the expected meter readings. You can find out which contracts do not yet have
any consumption data in the Utilities Industry menu under Device Management Meter Reading
Monitoring.
Note
Alternatively, you can create the billing order when you receive a consumption value. If you
do this, however, it is more difficult to monitor consumption values that are still missing.
Execute device replacement
If the information contained in the IDoc indicates that a device replacement is necessary, the
system executes replacement automatically. This is, however, only necessary if the
corresponding device information record in the supplier system has the same device number. If
this were not the case, it would be sufficient to add the consumption values that should be
allocated to a logical register and to save the detailed device replacement data separately in
table EMRDETAIL (detailed information on meter reading results).
- In the scenario that describes the use of device information records, the consumption data is
entered as a meter reading. It is necessary to define the registers of the device information

SAP AG Cookbook IDE Page 46 of 153

Cookbook
Intercompany Data Exchange


records as balancing consumption registers. BAPI_MTRREADDOC_UPLOAD is used to
update the consumption values.
- Other meter reading data such as previous and new meter readings, as well as any factors
that may have been used, are saved in table EMRDETAIL. This data is displayed on the bill
and must be included in the bill printout. A separate display function for the contents of
EMRDETAIL does not exist. No function modules are provided for reading the table.

The most important aspect of updating the consumption values is the question of how the supplier
finds the appropriate register, as the exact details of the distributors technical data are not known.
There are a number of options, all of which presuppose that the type of measured value is
recognizable in the IDoc by a standardized tag. According to the significance of the tag or tags, they
are compared with information from the register to determine which one is correct. The following
options are available:

1. The appropriate tag is allocated to the registers. You can find the register in question using the
device number and the register code.
2. Mapping IDoc data on specific register data such as register type and measurement unit. Two
mapping tables are available for this purpose and are described below.

For inbound consumption messages, it may be necessary to map coded data from the IDoc to IS-U-
specific descriptions. You can allocate IS-U register types to the register categories defined in the
IDoc in the Customizing menu under SAP Utilities Intercompany Data Exchange
Communication Control Communication Control of Inbound Messages Allocate Register Type.
You can also allocate an internal register type that is intended to recognize certain register types
within the program to the register categories (single rate rather than on-peak and off-peak rate, for
example).

You can allocate IS-U measurement units to the measurement units defined in the IDoc in the
Customizing menu under SAP Utilities Intercompany Data Exchange Communication Control
Communication Control of Inbound Messages Allocate Units of Measurement. You can also
allocate the following characteristics to the units of measurement:
Register is reactive, active or apparant
Processing control for aggregation
If several measurement values exist for the register, you can use the settings in this field to
determine whether to create totals, averages or maximum values from them.

Instead of the units of measurement from the IDoc, you can use any of the data from the
communications interface, from which appropriate conclusions about the characteristics can be
drawn.
4.1.4 Reversal
4.1.4.1 Outbound
Event BILLREVERS is triggered during billing reversal. The most common cause for a distributor to
reverse a billing document is a meter reading error. However, different rules apply in different
markets. In North America, for example, a reversal IDoc that is identical to the original IDoc apart
from a reversal indicator has to be sent. This is included in the allocated process module
ISU_IDOC_USAGE_MON_CREATE.




SAP AG Cookbook IDE Page 47 of 153

Cookbook
Intercompany Data Exchange


Note
Reversal is not currently included in the templates for the European market.

A problem may arise because the distributor has a different reason for reversal an incorrect rate,
for example. The bill reversal function does not recognize such differences automatically and always
triggers the event BILLREVERS. If you only want a reversal IDoc regarding consumption to be sent if
the meter reading result really is incorrect, you have to create your own mechanisms to ensure this
will happen. One option is to use the reversal reason, for example.

4.1.4.2 Inbound
As opposed to outbound reversal, the receipt of a reversal IDoc does not trigger a customer-defined
event and the same process module that determines the cases internally is called up.

Note
Again, reversal is only currently included in the templates for the North American market.

The relevant billing or invoicing documents are reversed. The meter reading result is also reversed.
Sequence problems may arise if a reversal IDoc for the bill is also sent when reversing an invoicing
document for the distributor. Again, market regulations dictate which reversal documents to send and
when.

4.1.5 Restrictions and Outlook
Currently, the process of sending consumption data can only be triggered from billing. This can lead
to problems in the following cases:

1. The distributor does not bill the grid usage itself (the supplier acts as billing agent using rate
ready billing). As a workaround, the distributor has no option but to execute minimum billing using
a rate that only provides consumption data and does not generate billing line items relevant to
posting.

2. Meter readings must be sent to the suppliers on time - when a device is replaced or when the
meter reading at move-in has to be reported, for example. These meter readings are also all
taken from billing during the sending process. However, due to market regulations, you should
send the meter readings as punctually as possible.
A workaround proves to be very complicated, particularly if consumption data is required, as this
has to be determined prior to sending. Function modules are available for this purpose however
they only supply the correct consumption value for electricity. For the gas procedure, the exact
consumption can often only be determined during billing (also because certain data isnt available
until later). Another problem is the absence of triggered events. For customer-specific
programming without modification, you must use the BOR events
MeterReadingDocument.Confirmed or MeterReadingDocument.Released. Since the events are
triggered for each meter reading result, further logic is required to determine when all meter
reading results for a point of delivery are available so that the appropriate IDoc can be sent.



SAP AG Cookbook IDE Page 48 of 153

Cookbook
Intercompany Data Exchange


Note
Ensure that no events are triggered when you change or delete meter reading results as this
would mean that the supplier is not automatically informed of the changes.
4.2 Sending and Receiving Billing Data
This unit deals with the process of creating outbound and receiving inbound electronic bills. The
basis for this is the IS-U billing document.
This unit does not explain how to select other contract account items (receivable or payable). The
integrated process of payment agreement is also only touched upon.
4.2.1 Outbound
There are two reasons why it may be necessary to send billing data:
1. In a bill ready scenario; for example, the distributor creates the bill, sends it to the supplier and
awaits payment.
2. In a rate ready scenario; for example, the supplier creates the bill and sends it to the distributor
for information and monitoring reasons.
4.2.1.1 Bill Ready
Firstly a description of the process for a bill ready scenario:

I nvoi c i ng
Report REDI SND1
Tabl e
ERDK
(no
pr i nt out )
Event modul e f or preparat i on
Of bi l l i ng l i ne i t ems
Proc ess modul e f or
pr epar at i on of I Doc
I doc
wi t h bi l l dat a
Tabl e
DFKKTHI
Post i ng i n FI -CA
Event
I NV_CREATE




SAP AG Cookbook IDE Page 49 of 153

Cookbook
Intercompany Data Exchange


Invoicing triggers the transfer of billing data. Invoicing occurs at contract account level, which means
that you can select different points of delivery (and therefore contracts) for joint invoicing. You can
also jointly select several billing periods for invoicing, even for just one contract.
Bill data is sent based on the assumption that an electronic bill has to be created for for each relevant
billing document. This is reflected in table DFKKTHI, which is created when the invoicing document is
posted. During posting, an open item is generated for each relevant billing document and an entry is
made in table DFKKTHI as a result.


Caution
If you want to invoice and send several billing documents simultaneously, you have to
calculate the value-added tax separately for each one. In order to do this, you must first set a
presorting key in the corresponding schema, to which function module ISU_BILL_TYPE_IDE
is allocated in Customizing (Invoicing Bill Printout Define Sort Criteria for Bill Printout).


Note
The invoicing documents should be separated according to the same logic and the appropriate
number of invoicing documents should be created in invoicing.
Ideally, a separate invoicing unit would be generated for each billing document that is sent
electronically. This would guarentee that an electronic bill is uniquely allocated to an invoicing
document. In this case, the presorting procedure described above would not be necessary.
At the very least you should separate the invoicing documents into different invoicing units in
the following cases:

The selected billing documents cover several periods and include a supplier change
The selected billing documents cover more than one period and include a change from a
regulated scenario to a deregulated scenario
You can use FI-CA event R403 to define the invoicing units for each billing document. No
example coding is supplied with this event as the distribution described is not always necessary
and other grouping criteria may also exist.

The billing data is sent in a second step. Table DFKKTHI, which is updated in invoicing, is used for
this purpose. Amongst other things, this table is used to control the sending of electronic bills. During
updates, all activities that deal with the actual bill creation process are taken into consideration. If the
billing data is to be sent electronically, a bill printout is not normally required. Therefore, the
respective billing documents are flagged do not print by default. If, in exceptional cases, you do need
to print the bill, you can convert the print parameters in FI-CA event R412.

You can define which other posting procedures to take into account in the Customizing settings for
IDE under Communication Control Communication Control of Outbound Messages Define
Accounts Receivable and Payable Items Relevant to Communication. Therefore, table DFKKTHI
(Transfer Records for Invoice Issue by Third Party) contains only those postings from accounts
receivable and payable that contain procedures defined in the Customizing table (and only these can
be sent to the supplier as a receivable).

For the actual creation of the IDoc, you have to start report REDISND1 (Create Electronic Bills).
Scheduling of the report is done using Job Scheduling in accordance with market requirements.
As of Add-on Support Package 8, you can schedule the report as a mass activity (transaction
MEER).

SAP AG Cookbook IDE Page 50 of 153

Cookbook
Intercompany Data Exchange


Report REDISND1 has two major tasks:
1. Selecting the relevant bills and creating the respective items in accordance with table DFKKTHI
2. Sending electronic bills (by calling up the appropriate templates)

Cases where special treatment is necessary may arise in some markets. Some such cases are
described here:
1. You only want to send part of the distributor bill electronically. For this purpose, you have to
create two separate invoicing documents in invoicing. You can do this using event R403. For the
document that is not sent electronically, use event R412 to set the print parameters to print.
2. You want to send the complete distributor bill on paper. In event R412, set the print parameters
to print. We recommend that you still use report REDISND1 so that you can at least use the
payment tracking function. Using communication control with the appropriate settings, you can
prevent the IDoc from being sent or you can define a company-specific version of REDISND1.
3. The distributor bill contains items with both the payment methods Advance Payment and
Customer Payment. In the standard system, this distinction is made at contract level and the
methods cannot be set apart. For cases such as this, you can define company-specific tables, in
the implementation project, that enable you to identify the method of payment for each document
line item (according to transaction, for example).
4.2.1.2 Rate Ready
In rate ready, the bill is sent for information purposes. This means that it is not necessary to send
other accounts receivable and payable items that are not part of the bill. This is recognized
automatically when items are assigned to a contract account during posting and table DFKKTHI is
not updated. To send postings that have been electronically assigned to a contract account, you
require a company-specific development. If there are more accounts receivable and payable items
on the current bill that have to be invoiced and sent to a third party, you have maintain the relevant
transactions in the Customizing settings for IDE under Communication Control Communication
Control of Outbound Messages Define Accounts Receivable and Payable Items Relevant to
Communication.

4.2.2 Inbound
Since an individual posting of inbound receivables does not occur for the sole provider, you have to
differentiate between sole provider and billing agent when you receive billing data.

The templates were designed based on the assumption that the consumption data is sent
separately. If you need to take meter readings and consumption data from the bill IDoc and update
them as meter reading results, you have to adjust the templates to meet the conditions of the
respective company in the implementation project.
4.2.2.1 Billing Agent


SAP AG Cookbook IDE Page 51 of 153

Cookbook
Intercompany Data Exchange


I Doc
w i t h bi l l
dat a
Event
I NV_I NBND
Pr oc ess modul e
i nbound bi l l
Event modul e i n I Doc
Cr eat e manual
bi l l i ng doc ument
Bi l l i ng
doc ument s
Tabl e
EREFDI SSUP
Cr eat e r ef er enc e t o
c r eat ed doc ument


A fundamental characteristic of the billing agent scenario is that the billing consolidator (the supplier
for example) has to invoice the received bill. The reasons for this are:
1. The received bill (from the distributor) should appear on the customer bill together with
receivables from consumption billing
2. The distributors receivables should be paid to the third party, on behalf of the third party using a
separate posting run.

A manual billing document is created from the inbound bill data, so that the received bill can be
invoiced. A billing document is created for this purpose in the process module and updated in the
background of the manual billing document.
A billing document requires much data that is specific to IS-U and therefore cannot be completed by
mapping the IDoc data to the billing document data. The process module has to provide the
necessary logic, for example, how to enter data, such as rate or meter reading unit, that is typical to
billing. Company-specific tables are necessary here to convert IDoc data into IS-U data.

Table EINLITYPETRANS (Allocation of Document Line Items) allows you to map an IDoc line item
type to an IS-U line item type. In addition to a simple conversion to an IS-U line item type, this table
also allows several relevant fields of single billing line items to be occupied:


SAP AG Cookbook IDE Page 52 of 153

Cookbook
Intercompany Data Exchange




Field Short Description
BUCHREL Billing line item relevant to posting
PRINTREL Billing line item is relevant to printing
BETRSTREL Amount of billing line item is statistically relevant
STGRAMT Amount statistics group
LINESORT Presorting of billing line items in billing schema
TVORG Sub-transaction for line item
GEGEN_TVORG Off-setting transaction for sub-transaction of billing line item
MWSKZ Tax code

You can find this table in the Customizing settings for IDE under Communication Control
Communication Control of Inbound Messages Allocate Line Item Types. By making the
appropriate settings you can, for example, exclude certain line items from printing or ensure that
other line items only appear in the statistics.

If you have further requirements, you must create your own company-specific table with the
appropriate key definitions.

In another mapping table, you can determine an IS-U rate category depending on which service
provider is the sender, and the rate data provided in the IDoc. You can find this table in the
Customizing settings for IDE under Communication Control Communication Control of Inbound
Messages Allocate Rate Categories to Service Providers.

Note
You can also use this table for enrollment in a rate ready scenario. For example, the distributor
notifies the supplier of the rate, which the supplier then uses to bill the customer on behalf of
the distributor. The distributor chooses his own rate description, which can then be allocated to
an IS-U rate category.

To be able to invoice the received bill, you must create a manual billing document from the inbound
billing data. You must ensure that the ERCH-ORIGDOC indicator is set in this document. This allows
you to distinguish between this document and the manual billings created by the system. In this case,
the indicator can have one of two different values:
04 = Document from IDoc without delete function
A processor cannot manually reverse the manual document. This ensures that the autonomy
for the document is with the sender and the manual document can only be reversed by an
automated process (a reversal from the IDoc, for example).
05 = Document from IDoc with delete function
A processor can reverse the manual document manually.

Table EREFDISSUP (Reference Between Documents of Suppliers and Distributors) is updated in the
process module template and then used in the same process module for extended checks. The
reason for this is that we are dealing with a very sensitive transaction, in which it is easy to make
incorrect postings or payments.
In an automated process such as this, it must be clear whether the IDoc has been sent twice, for
example. Table EREFDISSUP also serves as a link between the sent bill and the manually created
billing document. You can also use the data available in this table for other purposes.



SAP AG Cookbook IDE Page 53 of 153

Cookbook
Intercompany Data Exchange



Note
SAP plans to replace this table with a general solution in the future. This means that the table
remains as it is and the implemented function can still be used. In future, however, it will not be
able to be used in the templates provided.

4.2.2.2 Sole Provider

I Doc
wi t h bi l l dat a
Event
I NV_I NBND
Process modul e
i nbound bi l l
Event modul e i n I Doc
Cr eat e manual
bi l l i ng doc ument
Bi l l i ng
doc ument s
Tabl e
EREFDI SSUP
Creat e ref erenc e t o
c reat ed doc ument
Tabl e
EPAYTHP

A fundamental characteristic of the sole provider scenario is that the bill received by the billing
consolidator is paid directly. Since it is not realistic in FI-CA for the third party receivables to be
posted individually due to the expected high volume, the receivables are aggregated. To make this
possible, the data necessary for posting is written in table EPAYTHP (Transfer Records for Third
Party Payments). This table then acts as the basis for aggregated posting and for sending IDocs
containing payment data. For more information, see Unit 5.

In addition, it is of course possible to create a manual billing document as described in the previous
section, billing agent. This makes sense if, for example, you need an informal report on transmission
charges for legal reasons. You can flag the document line items in the manual billing document as
not relevant to posting (and not relevant to statistics) in the Customizing settings for IDE under
Communication Control Communication Control of Inbound Messages Allocate Line Item
Types.


SAP AG Cookbook IDE Page 54 of 153

Cookbook
Intercompany Data Exchange


4.2.2.3 Outlook: Creating a Bill Manually
In some deregulated markets (such as Germany), the introduction of a national, electronic standard
for bills is unlikely to occur in the near future. It is therefore necessary to provide a function that
allows transmission bills to be created manually and that also allows them to be processed in the
same way as electronic bills.
All the tools required to create this function yourself are available:
Create a front office process. Enter the necessary data in a new entry template. From here you can
create the manual billing document and/or EPAYTHP table. If necessary, you can also enter the
meter readings and consumption values from the bill and they are updated as meter reading results.


4.2.3 Reversal
4.2.3.1 Outbound
When an invoice is reversed, it is assumed that a reversal IDoc containing bill data is sent and that,
apart from a reversal indicator, it corresponds to the original IDoc. Therefore, the sending of the IDoc
is triggered by the exact same mechanism as in regular invoicing. This means that tables EITEDI
(Temporary Index Selection for Invoicing EDI Transfer) and DFKKTHI (Transfer Records for
Issuing of Bill by Third Party) are updated and processed using report REDISNDI (Create Electronic
Bills). The same event is created as in invoicing (INV_CREATE). This means that the process
module template distinguishes between reversal and non-reversal cases within the program.
An exception arises if the IDoc contains items from invoicing as well as items assigned to a contract
or items assigned to a contract account. If you reverse an item, the entire IDoc has to be sent with
reversed status. You can prevent the other items from also being reversed using appropriate
mechanisms.

4.2.3.2 Inbound
In the same way as when you send a reversed bill, no separate event is triggered when you receive
a reversed bill. Event INV_INBND is used instead. With the help of data from the IDoc, the process
module template is able to recognize a reversal and react accordingly. The following procedure takes
place:
If a manual billing document is created from the original bill, the system attempts to delete it. This
is, however, only possible if the document has not yet been billed.
If the manual billing document has already been billed, the system attempts to reverse it. This is,
however, only possible if the document has not yet been invoiced.
If the manual billing document has already been invoiced, the system creates a new manual
billing document containing the appropriate negative amount.
4.2.4 Sending Manual Billing Documents
Manual billing documents are an exception. They can be created at any time and for any contract. If
the contract belongs to a deregulation scenario, in which the third party is a billing consolidator, the
system works on the assumption that the manually created billing document should also be sent
electronically. In invoicing, the manual billing document is allocated to the automatic billing document
of the respective contract that has the most recent end of billing period. When you send the IDoc, the
bill data from both billing documents is grouped together and treated as a bill.
To be able to send manual billing documents, you must adhere to the following rules and restrictions:

SAP AG Cookbook IDE Page 55 of 153

Cookbook
Intercompany Data Exchange


You cannot send manual billing documents separately. Go to the Header data tab page of the
document and in the Additional data group frame, select the Joint invoicing (Only invoice
document jointly with automatic document) field.
To prevent manual documents from being sent, you have the following options:
o Modify the function module ISU_COMEV_PROCESS_INVOICE (this is the event
module that is called in report REDISND1) and make the appropriate changes to the
program.
o Create a new non-deregulated customer contract, to which you can then allocate the
manual documents.
o Make an entry in the ERCH-ORIGDOC field when you create the manual document.
This field is initially used to distinguish between manual documents from external
systems and your own manual documents. As a consequence, documents are not
sent electronically. It is not possible to maintain the ORIGDOC field when creating
manual documents. You have to either use a modification or you can use billing
enhancement EBIA001 to make entries in the field.

Sending consumption data does not trigger a communication event when you create manual
documents as it does for billing. If necessary, you can create the event yourself. As soon as the IDoc
containing the consumption data has been sent, a manual document can be treated as an automatic
document and the restrictions mentioned above no longer apply. You can find the modifications
required to do this in note 427070.

SAP AG Cookbook IDE Page 56 of 153

Cookbook
Intercompany Data Exchange



4.3 Sending and Receiving Payment Advice Notes
4.3.1 Outbound
When sending data, it is important to distinguish between the sole provider and billing agent, as the
basis of the data is different. Therefore, the sending process is triggered by different reports, which
you need to schedule accordingly.
For the billing agent, payments to the distributor are not generated on receipt of the bill but when the
bill is posted to FI-CA. Whether this occurs in invoicing itself (advance payment) or in the customer
payment transaction is not important in this case. The relevant postings are stored in table
DFKKTHP. This table is then the basis for report REREMITADV, which is used to create IDocs. The
process for the billing agent is illustrated in the following graphic.
FI -CA Post i ngs
Repor t REREMI TADV
Pr oc ess modul e f or pr epar at i on
of I Doc
Event
REMI TADV
I Doc w i t h
payment dat a
Tabl e
DFKKTHP













SAP AG Cookbook IDE Page 57 of 153

Cookbook
Intercompany Data Exchange


For the sole provider, table EPAYTHP is completed on receipt of the bill (table EPAYTHP has the
same functions as table DFKKTHP in the billing agent scenario). At the same time, the IDocs are
created using report REREMITADV_SOLEPRV. The process for the sole provider is illustrated in the
following graphic:

Repor t
REREMI TADV_SOLEPRV
Pr oc ess modul e f or pr epar at i on
of I Doc
Event
REMI TADV
I Doc w i t h
payment dat a
Tabl e
EPAYTHP

The same templates are used for the actual preparation in IDoc format and for sending the IDoc. An
IDoc is not sent for every bill that is received. As is usual in all markets, the template contains a
repetition group that includes individual data. You can only send the IDoc if all the individual bills
have been posted in FI-AP (accounts payable). This posting is triggered by other reports that you
must also schedule appropriately. In the billing agent scenario, report RECTHP01 posts the IDoc and
in the sole provider scenario, report RECTHP02 posts the IDoc.

The IDocs that were created in the templates contain the complete payment data of an aggregated
posting for every payment recipient (= distributor). Therefore, the sum of all individual amounts
contained in the IDoc should equal the amount that is actually transferred to the distributors bank
account.

Note
The template used to create IDocs in the US standard ANSI X. 12, splits the required IDoc
(EDI820) into three separate IDocs. The reason for this is, however, no longer valid. In future,
the necessary adjustments will be made to the template.

The risk involved with this procedure is that certain capacity limits may be exceeded. Such cases are
not intercepted in the templates. If you want to take this into account, you must make the necessary
adjustments to the templates.

SAP AG Cookbook IDE Page 58 of 153

Cookbook
Intercompany Data Exchange



The following cases have arisen in the past:
Size restrictions for the IDoc. Because, theoretically, there is no limit to the number of payments
that can appear as a repetition group, the size of the IDoc is restricted from a technical viewpoint.
Whilst, from SAPs point of view, it is practically impossible to exceed this limit, the other systems
represent a bottleneck. Therefore, when determining the maximum number of payments in an
IDoc, you should use the widest possible bottleneck as a basis.
Amount restrictions for the total amount. This restriction is usually due to legal or company-
internal regulations for payment transactions (and not for exceeding a field length in the IDoc).
This means that the total payment from the suppler to the distributor may not exceed 99 million,
for example. If such a case arises, the report has to take into account an appropriate limit for
posting in FI-AP (accounts payable), and if necessary, create more postings. As the aggregated
posting is the basis for creating an IDoc, in this case, when you create an IDoc, you do not have
to do anything.

4.3.2 Inbound

I Doc
w i t h payment dat a
Event
REM_ADV_I N
Pr oc ess modul e f or c r eat i on
of payment l ot
Event modul e i n I Doc
Pr oc essi ng t he payment l ot
FKK_PAYMENT_BATCH


When you create payment advice notes, a payment lot is created from the IDoc. From the postings
that result, you must ensure on the one hand that the relevant receivables are compared on an
individual customer basis, and on the other hand that the total receivables are compared with regard
to the supplier.
4.3.3 Reversal
When you send payment advice notes, no separate reversal procedure exists. The postings in FI-CA
are used to complete table DFKKTHP, whether they are reversal postings or not. At the same time,
inbound bill reversals in the sole provider scenario, result in entries made in table EPAYTHP that are
recognizable as reversals but are subject to the same sending process as non-reversal entries.

SAP AG Cookbook IDE Page 59 of 153

Cookbook
Intercompany Data Exchange


4.4 Periodic Billing
Periodic billing includes everything to do with periodic meter reading, periodic billing and payment.
The reason for this is that all these activities are connected and must be regarded as general
activities. This unit focuses on those functions that are needed to support the general process. This
is explained below using three typical scenarios as examples. For details on sending and receiving
different messages, see the previous units.

In markets where meter readings are carried out monthly (North America, for example), billing carried
out by the supplier is based on meter reading results from the distributor. Therefore the distributor
and the supplier need to come to an agreement. The following examples are based on this
procedure, which also corresponds to the templates that are provided to the North American market.
In markets that do not have this strong link of supplier billing and distributor meter reading, periodic
billing is considerably easier. If the distributors meter reading pattern does not match that of the
supplier, the supplier may choose to acquire the meter reading results by introducing meter reading
by the customer, for example.

SAP AG Cookbook IDE Page 60 of 153

Cookbook
Intercompany Data Exchange



4.4.1 Example 1: Supplier as Billing Agent with Rate Ready
In this example, let us assume that we are dealing with a customer payment transaction. You can
find the underlying data model in section 3.6.4. (Possible Deregulation Scenarios)

The general process is illustrated in the following diagram:

Create
dummy bill
Create
consumption billing
Consumption data
Manual bill
Bill data
(for info)
Invoice
bills
Bill
to customer
Compare
receivables and
payments
Payment data
Distributor Supplier
Create
grid billing
DFKKTHP
Customer pays
Post to
distributor account
DFKKTHI
Payment (FI-payment run)

Sending bill data to the distributor is optional and serves only for bill control. A detailed model to
show the process of comparing the bill data and the actual payments received by the distributor does
not yet exist. A solution using the mechanisms currently available is, however, conceivable.

SAP AG Cookbook IDE Page 61 of 153

Cookbook
Intercompany Data Exchange



4.4.2 Example 2: Distributor as Billing Agent with Bill Ready
In this example, let us assume that we are dealing with a customer payment transaction. You can
find the underlying data model in section 3.6.4 (Possible Deregulation Scenarios).

Create
grid billing
Create
consumption billing
Consumption data
Manual
bill
Bill data
Invoice
bill
Bill
to customer
Compare
receivables and
payments
Payment data
Distributor Supplier
DFKKTHP
Post to
supplier account
DFKKTHI
Invoice
bills
Payment (FI-payment run)

The transaction used to compare receivables and payments is essentially a type of posting
mechanism. The data from table DFKKTHI can also be used to support the transaction. A double
arrow indicates this.

SAP AG Cookbook IDE Page 62 of 153

Cookbook
Intercompany Data Exchange



4.4.3 Example 3: Supplier as Sole Provider
You can find the underlying data model in section Possible Deregulation Scenarios.

Create
grid billing
Create
consumption billing
Consumption data
Bill data
Invoice
bill
Bill to
customer
Compare
receivables and
payments
Payment data
Distributor Supplier
Invoice
grid bill
DFKKTHI
Posting to
distributors account
EPAYTHP
Payment (FI-payment run)

The main difference between sole provider and billing agent is clearly seen in this graphic. Creation
of the consumption bill is created independently from the receipt and payment of the grid usage bill.

Note
Once the supplier has received the bill data, it is of course possible (although not shown in the
above graphic) to automatically create a manual billing document from the inbound bill. You
can then invoice it for information purposes along with consumption billing and print it on the
bill. This is necessary in markets that demand separate statements on the bill for consumption
and grid usage, for example.
Alternatively, the supplier can create the necessary billing lines for the bill by reproducing the
relevant rate steps. This would, however, be purely informative.



SAP AG Cookbook IDE Page 63 of 153

Cookbook
Intercompany Data Exchange



4.4.4 Cross Reference Number
In all of the examples, it is essential that the distributor can allocate both the bill and payment to the
consumption data that was originally sent. In the distributor as billing agent example, the supplier
also needs this data.
For this reason, a cross-reference number (CRN) that remains the same throughout the entire
process is required. In some markets, its use is already a legal requirement and is a predefined part
of the communication process.
The assignment of a CRN, as well as the recognition and further processes that result, is part of the
IDE component. The basis for all this is table ECROSSREFNO (reference number IDoc), in which
the CRN is managed.
The CRN is used in the distributor as billing agent example. In the other examples, it is used as
appropriate.

Create
grid billing
Create
consumption billing
Consumption data
4711
Manual
bill
Bill data 4711
Invoice
bill
Bill to
customer
Compare
receivables
and payments
Payment data 4711
Distributor Supplier
DFKKTHP
4711
Post to
supplier account
DFKKTHI
4711
Invoice
bills
ECROSSREFNO
4711
ECROSSREFNO
4711


SAP AG Cookbook IDE Page 64 of 153

Cookbook
Intercompany Data Exchange



The uses of the CRN, as shown in the examples, are integrated into the templates. The procedure is
as follows:
1. When the distributor sends consumption data, the CRN is created in the distributors system and
saved in table ECROSSREFNO.
2. The CRN is part of the IDoc used to send consumption data.
3. When the supplier receives the IDoc containing consumption data, the CRN is saved in table
ECROSSREFNO in the suppliers system.
4. Table DFKKTHI, which is created during invoicing of the supplier bill, contains the CRN for
information purposes.
Note
In special cases, you can use FI-CA event R414 to override the CRN. Normally, however, this
should not be necessary.

5. The CRN is part of the bill IDoc.
6. On receipt of the bill IDoc, plausibility checks can be executed in the distributors system. These
show whether or not the bill relates to consumption data originally sent by the distributor.
7. During advance payment in invoicing for the distributor, an entry is created in table DFKKTHP
(transfer records for billing on behalf of third party) that also contains the CRN.
8. Again, CRN is part of the payment data IDoc.
9. On receipt of the payment data IDoc, plausibility checks can be executed in the suppliers
system.

You can allocate the CRN as you wish. You can adjust it in the appropriate module of event
BILLCREATE to meet your own requirements. In order to be independent from this CRN, an internal
CRN that is not visible to external users is used within the program.

If the CRN is only intended for restricted use, you must consider the fact that the templates are, to a
large extent, programmed using the CRN. You must therefore adjust those templates accordingly.
Because, in some systems, the existence of a CRN is absolutely necessary for communication
purposes, you may not deactivate it. If the CRN is not needed or if it is needed in a different form, it
must still run, but without effect.

The above example is based on advance payment.
For customer payment, the CRN is entered in the relevant open items in table DFKKOP. This entry is
then copied to table DFKKTHP (Transfer Records for Billing on Behalf of Third Party) on receipt of
payment from the customer.



SAP AG Cookbook IDE Page 65 of 153

Cookbook
Intercompany Data Exchange


5 Dynamic Business Processes
Dynamic business processes are triggered by business transactions that result in changes to the
customers data environment. For the most part, these processes are independent of the
deregulation scenario. The actual implementation of the processes can differ according to the
communication rules, which determine who communicates with whom and using which format.
5.1 Change of Supplier
Changing supplier is a very complex process on the deregulated market. The following graphic gives
an overview of a possible version of this process, in which the customer switches to a new supplier.

New
supplier
Former
supplier
Distributor
Customer
Transmission
company
Supply request
Notice
Confirmation of notice
Notification of change of supplier (list of customer switches/new
customer enrollments)
Confirmation of change of supplier
(load profile/group allocation, annual energy amount)
Customer switch list
Register changed schedules
Final invoice
Meter values
Determine meter reading
Meter values
Register changed schedules
Greeting

The communication flows can differ according to the market rules, as can the time and scope of the
data exchanged between service providers. Further service providers can also be involved in this
process. This is the case when meter reading or billing companies are also involved or when
communication takes place using a clearing house. However, the basic flow is nearly the same.
The following sections describe the individual processes that have to be executed in the service
providers systems in order to implement the overall process. The sections describe the Customizing
settings and the processes for the following service providers:
New supplier
Former supplier
Distributor

SAP AG Cookbook IDE Page 66 of 153

Cookbook
Intercompany Data Exchange


5.1.1 New Supplier
The new supplier normally has to create master data in its system for the new customer. Different
numbers of contracts or non-billable services are created depending on the deregulation scenario. In
the case of a new supplier, this constitutes enrollment with a new customer. The following proposal
mechanisms are used in service determination:
Services based on operational area
Services based on service provider relationship
You define the procedure for service determination in Customizing for SAP Utilities under
Intercompany Data Exchange Basic Settings Define Control Parameters.

Manual enrollment:
move-in
Automatic
enrollment:
workflow
Proposal procedure based
on operational area
Proposal procedure based
on service provider
relationships
CRM workflow or SD
workflow with proposal
procedure based on
operational area
SD workflow or CRM
workflow with proposal
procedure based on service
provider relationships
Enrollment
Manual selection of
installations and
manual maintenance of
fields in contract and
NB service
Proposals for NB
services only
Workflow uses master
data generator to
create contracts and
NB services and
execute move-in
Proposals for contracts
and NB services


The following sections describe
Manual enrollment
o With proposal procedure by operational area
o With proposal procedure by service provider relationship
Automatic enrollment
o With the mySAP SD component and proposal procedure by operational area
o With the mySAP CRM component and proposal procedure by service provider
relationship

Caution
Manual enrollment does not trigger any communication events, so that IDE communication does not
take place.


SAP AG Cookbook IDE Page 67 of 153

Cookbook
Intercompany Data Exchange


5.1.1.1 Manual Enrollment
Manual enrollment takes place during the move-in transaction. You can find this transaction in the
Utilities Industry menu under Customer Service Process Execution Move-In Create. Select
all the installations for which contracts are to be created. The system creates NB services
automatically according to the proposal procedure specified. You can edit these on the Deregulation
tab page. The new contracts are created for the selected installations. You must make entries
manually in the relevant fields in the contracts and NB services. The following graphic gives an
overview of the procedure:

Installation
Move-in with
manual entry
Contract
NB service
Enrollment Master data Customizing
Default
services


The alternative service determination procedures are described in greater detail in the following
sections and the Customizing settings are explained using examples.
5.1.1.2 Services Based on Operational Area
In this procedure, the services are defined for each operational area. The operational area, in which
the point of delivery is located, is the key to the default values for the services.

The operational area can be determined based on the point of delivery in one of the following ways:
1. If the point of delivery is allocated a grid, the grid is used to determine the distributor and the
distributor is then used to determine the operational area.
2. If the point of delivery is not allocated a grid, the system reads the grid from the regional
structure of the address of the installation by comparing the voltage level of the installation
with that of the regional structure. The grid is used to determine the distributor and the
operational area is then determined from the distributor.
If it is not possible to determine a grid, no services are proposed.









SAP AG Cookbook IDE Page 68 of 153

Cookbook
Intercompany Data Exchange


Both of the above options are illustrated in the following graphic:
Point of delivery Grid Distributor
Operational
area
Installation
Premise
Grid Distributor
Address
(regional structure)
Connection object
1
1..*
1
1..*
1 1
1 1
1
1
1
1
1 1
1 1
1
2

To create the link between the grid, distributor and operational area, you must make the following
Customizing settings for Intercompany Data Exchange beforehand:

1. Define operational area
(Basic Settings Define Operational Area)

Operational area Name of operational area
0001 Operational area 0001
0002 Operational area 0002
0003 Operational area 0003
0004 Operational area 0004
0005 Operational area 0005

2. Define grid
(Integration with Energy Data Management Define Grid)

Grid Name Higher level grid
G001 Grid 001
G002 Grid 002
G003 Grid 003
G004 Grid 004
G005 Grid 005

3. Allocate service provider to grid
(Integration with Energy Data Management Grid Allocation Allocate Service Provider to
Grid)

SAP AG Cookbook IDE Page 69 of 153

Cookbook
Intercompany Data Exchange



Grid Valid to Valid from Distributor
G001 12/31/9999 01/01/1980 GRID01
G002 12/31/9999 01/01/1980 GRID02
G003 12/31/9999 01/01/1980 GRID03
G004 12/31/9999 01/01/1980 GRID04
G005 12/31/9999 01/01/1980 GRIDZ05

4. Allocate voltage levels to grid
(Integration with Energy Data Management Grid Allocation Allocate Voltage Levels to Grid)

Grid Voltage level
G001
G002
G003
G004
G005

5. Allocate operational area
(Service Provider Allocate Operational Area)

Distributor Operational area
GRID01 0001
GRID02 0002
GRID03 0003
GRID04 0004
GRID05 0005

To ensure that the second determination method works, you must enter a grid, in accordance with
the voltage level, in the Grids group box for the city or street you find under Regional Structure
Postal City or Street in the Utilities Industry menu, and you must also activate the regional
structure globally.

If you overwrite the reference implementation for the BAdI method ISU_IDE_COM_CONTROL
OPAREA_DETERMINE, you can use criteria of your choice instead of the distributor to determine
the operational area.

If you have made the settings just described for determining the operational area, you can define the
proposals for the services for each operational area in Customizing under Process Management
Enrollment Services Based on Operational Area Define Service Types. To keep the
Customizing settings flexible and ensure that several scenarios can be covered at once, you can
enter services for all the desired service types in this Customizing step, even in cases where a
contract is actually required. If a contract is created for a service type during move-in, the proposed
NB service is not created for this service type.
In move-in, a contract takes priority over a non-billable service if both have the same service type.

The following sections describe the data structures that must be set up in order to map the example
scenarios described (see section 3.6.4).

The examples use supplier SUPP and distributor GRID01-05. The number of the operational area
corresponds to the number of the example. The payment class in the contract or NB services serves
as an additional criterion for identifying the scenarios. The payment method allocated to the payment
class is decisive.

SAP AG Cookbook IDE Page 70 of 153

Cookbook
Intercompany Data Exchange



Example 1: Supplier as Billing Agent with Rate Ready (Suppliers Perspective)

Two contracts are to be created in the suppliers system: one for delivery and one for distribution.

1. Preparation
You must make the following entries in the deregulation fields for the installations:

Installation Service type Billing service provider
Supplier SUPP GRID
Distributor GRID GRID

Customizing:
NB services are not required, so you do not need to make any entries in the proposal table for
NB services.
However, if further scenarios are to be supported, for example, creating an NB service instead of
a contract for the distributor, you must define a suitable proposal in the Customizing settings for
Intercompany Data Exchange under Process Management Enrollment Services Based on
Operational Area Define Service Types.

Operational area Service
type
Service provider Optional
service
0001 GRID GRID01

The NB service is not created if a contract is created instead during move-in.

2. Execute move-in
Choose an installation with the Delivery service type and an installation with the Grid service type.
Make the following entries in the deregulation fields for the contracts:

Contract Service
provider
Billing service
provider
Payment
class
Supplier SUPP SUPP
Distributor GRID01 SUPP ADV or
CUST
(payment
class with
payment
method
Advance
payment or
Customer
payment)

The Deregulation tab page in the move-in transaction should remain blank.

SAP AG Cookbook IDE Page 71 of 153

Cookbook
Intercompany Data Exchange



Example 2: Distributor as Billing Agent with Bill Ready

A contract for the supplier and an NB service for the distributor are to be created in the suppliers
system.

1. Preparation
You must make the following entries in the deregulation fields for the installation:

Installation Service type Billing service provider
Supplier SUPP
SUPP

Customizing:
You define the proposal for the non-billable service in Customizing for Intercompany Data
Exchange under Process Management Enrollment Services Based on Operational Area
Define Service Types.

Operational
area
Service type Service provider Optional
service
0002 GRID
GRID02


2. Execute move-in
Select the suppliers installation.
Make the following entries in the deregulation fields in the contract:

Contract Service provider Billing service
provider
2. Payment
class
Supplier SUPP GRID02 ADV or
CUST
(payment
class with
payment
method
Advance
payment or
Customer
payment)

The Deregulation tab page in the move-in transaction must contain the following entries.
You can also enter further fields for the service here.

Service Service
type
Service provider Payment
class
Distributor GRID GRID02


SAP AG Cookbook IDE Page 72 of 153

Cookbook
Intercompany Data Exchange



Example 3: Supplier as Sole Provider

A contract is to be created for the supplier and an NB service for the distributor.

1. Preparation
Make the following entries in the deregulation fields for the installation:

Installation Service type Billing service provider
Supplier SUPP SUPP

Customizing:
You define the proposal for the non-billable service in Customizing for Intercompany Data
Exchange under Process Management Enrollment Services Based on Operational Area
Define Service Types.

Operational
area
Service
type
Service provider Optional
service
0003 GRID GRID03

2. Execute move-in
Select the installation with the Delivery service type.
Make the following entries in the deregulation fields for the contract:

Contract Service provider Billing service
provider
Payment
class
Supplier SUPP SUPP

You must enter the payment class of the NB service on the Deregulation tab page in the
move-in transaction, so that the sole provider scenario is identified. You can also enter
further fields from the service on this tab page.

Service Service
type
Service provider Payment
class
Distributor GRID GRID03 SOLE
(payment
class with
payment
method
Sole
provider)


SAP AG Cookbook IDE Page 73 of 153

Cookbook
Intercompany Data Exchange



Example 4: Dual Billing

A contract is to be created for the supplier and an NB service for the distributor.

1. Preparation
Make the following entries in the deregulation fields for the installation:

Installation Service type Billing service provider
Supplier SUPP SUPP

Customizing:
You define the proposal for the non-billable service in Customizing for Intercompany Data
Exchange under Process Management Enrollment Services Based on Operational Area
Define Service Types.

Operational
area
Service
type
Service provider Optional
service
0004 GRID GRID04

2. Execute move-in
Select the installation with the service type Delivery.
Make the following entries in the deregulation fields in the contract:

Contract Service provider Billing service
provider
Payment
class
Supplier SUPP SUPP

The Deregulation tab page in the move-in transaction must contain the following entries.
You can also enter additional fields for the service on this tab page.

Service Service type Service provider Payment
class
Distributor GRID GRID04


SAP AG Cookbook IDE Page 74 of 153

Cookbook
Intercompany Data Exchange



Example 5: Supplier and Distributor in one System

Two contracts are to be created in the suppliers system, one for the supplier and one for the
distributor. The supplier acts as Billing Agent and is therefore the contract partner who is in direct
contact with the end customer. Both service providers must be defined as service providers
managed in own system. This means you must select the Service Provider is Managed in Own
System field for these service providers in the Customizing settings for Intercompany Data Exchange
under Service Provider Define Service Providers.

1. Preparation
Make the following entries in the deregulation fields for the installations:

Installation Service type Billing service provider
Supplier SUPP SUPP
Distributor GRID GRID05 or SUPP

Customizing:
NB services are not required, so you do not need to make any entries in the proposal table for
NB services.

2. Execute move-in
Select the installations with the Delivery and Grid service type.
Make the following entries in the deregulation fields in the contract:

Contract Service provider Billing service
provider
Payment
class
Supplier SUPP SUPP
Distributor GRID05 SUPP

The Deregulation tab page in the move-in transaction should remain blank.


5.1.1.3 Services Based on Service Provider Relationship
Unlike the proposal procedure based on the operational area, the selection criterion for the default
values in this procedure is a combination of several parameters (grid, own service provider, other
service provider, enrollment type). The system determines default values for contracts and NB
services but only those for the NB services are used in manual move-in. The contracts are created
for the installations chosen manually.
The parameters are determined based on the point of delivery or installation. The determination
procedure in question is described here in more detail:
Grid
The grid is determined as follows:
1. A grid is entered for the point of delivery
2. If the point of delivery does not have a grid, the grid is read from the regional structure for
the installation address. The voltage level of the installation serves as a further selection
criterion for the grid.
If the system is unable to determine a grid, no services are proposed either.

SAP AG Cookbook IDE Page 75 of 153

Cookbook
Intercompany Data Exchange


To ensure that the second determination method works, you must enter a grid, in accordance with
the voltage level, in the Grids group box for the city or street you find under Regional Structure
Postal City or Street in the Utilities Industry menu, and you must also activate the regional
structure globally.
Own service provider
This is the service provider in whose system the process is run, for example, in this case, the
supplier. This service provider is flagged as managed in own system under Service Provider
Define Service Providers in Customizing for Intercompany Data Exchange.
Third party service provider
This is the other service provider that is relevant in choosing a certain scenario and its default
values in enrollment, for example, the distributor in enrollment in the suppliers system. This
parameter is used to propose the contracts but is not used in manual move-in, since only NB
services are proposed in that case.
Enrollment type
The enrollment type is determined as standard from the contract account class. For this purpose,
you must make at least the following settings in Customizing for Intercompany Data Exchange
under Process Management Enrollment Services Based on Service Provider Relationship:

1. Define enrollment type
You must define at least one enrollment type.

Enrollment type Text
0001 Standard

2. Determine enrollment type
You must allocate the enrollment type to a contract account class.

Enrollment type Contract account class
0001 0001

If you overwrite the BAdI method ISU_IDE_ENROLL ENROLL_TYPE_DETERMINE, you can
specify your own criteria for determining the enrollment type.

The following examples use the supplier SUPP and distributors GRID01-GRID05. Grids G001-G005
are named in the same way as the example number.

The examples describe the Customizing and master data settings that you must make beforehand
and the data that you must enter in manual move-in. The procedure based on the service provider
relationship also allows default values for contracts. However, only the proposals for the NB services
are used in the manual process.

SAP AG Cookbook IDE Page 76 of 153

Cookbook
Intercompany Data Exchange



Example 1: Supplier as Billing Agent with Rate Ready

Two contracts are to be created in the suppliers system, one for the supplier and one for the
distributor.

1. Preparation
Make the following entries in the deregulation fields for the installations for the delivery
and grid:

Installation Service type Billing service provider
Supplier SUPP SUPP
Distributor GRID SUPP

Customizing:
NB services are not required, so you do not need to make any entries in the proposal
table for NB services.

2. Execute move-in
Select the installation with the Delivery service type and that with the Grid service type.
Make the following entries in the deregulation fields in the contracts:

Contract Service provider Billing service
provider
Payment
class
Supplier SUPP SUPP
Distributor GRID01 SUPP ADV or
CUST
(payment
class with
payment
method
Advance
payment
or
Customer
payment)

The Deregulation tab page in the move-in transaction should remain blank.

Example 2: Distributor as Billing Agent with Bill Ready

A contract for the supplier and an NB service for the distributor are to be created in the suppliers
system.

1. Preparation
Make the following entries in the deregulation fields in the installation:

Installation Service type Billing service provider
Supplier SUPP SUPP


SAP AG Cookbook IDE Page 77 of 153

Cookbook
Intercompany Data Exchange


Customizing:
You define the proposal for the non-billable service in the Customizing settings for
Intercompany Data Exchange under Process Management Enrollment Services
Based on Operational Area Define Service Types.

Grid
Own
service
provider
Enrollment
type
Service
type
Third
party
service
provider
Payment
class
Optional
service
G002 SUPP 0001 GRID GRID02

2. Execute move-in
Select the suppliers installation.
Make the following entries in the deregulation fields for the contract:

Contract Service
provider
Invoicing service
provider
Payment class
Supplier SUPP GRID02 ADV or CUST
(payment class
with payment
method Advance
payment or
Customer
payment)

The Deregulation tab page in the move-in transaction must contain the following entries.
You can also enter other fields for the service on this tab.

Service Service
type
Service provider Payment class
Distributor GRID GRID02


Example 3: Supplier as Sole Provider

A contract for the supplier and an NB service for the distributor are to be created in the suppliers
system.

1. Preparation
You must make the following entries in the deregulation fields for the installation:

Installation Service type Billing service provider
Supplier SUPP
SUPP

Customizing:
You define the proposal for the non-billable service in Customizing for Intercompany
Data Exchange under Process Management Enrollment Services Based on
Operational Area Define Service Types.

SAP AG Cookbook IDE Page 78 of 153

Cookbook
Intercompany Data Exchange




Grid Own
service
provider
Enrollment
type
Service
type
Third
party
service
provider
Payment
class
Optional
service
G00
3
SUPP 0001 GRID GRID03 SOLE
(payment
class with
payment
method
Sole
provider)


2. Execute move-in
Select the installation with the Delivery service type.
You must make the following entries in the deregulation fields in the contract:

Contract Service provider Billing service
provider
Payment class
Supplier SUPP SUPP

You must enter the payment class for the NB service on the Deregulation tab page for
the move-in transaction so that the sole provider scenario is identified. You can also
enter other fields for the service in this field.

Service Service
type
Service
provider
Payment class
Distributor GRID
GRID03
SOLE (payment class
with payment method
Sole provider)


Example 4: Dual Billing

A contract for the supplier and an NB service for the distributor are to be created in the suppliers
system.

1. Preparation
You must make the following entries in the deregulation fields for the installation:

Installation Service type Billing service provider
Supplier SUPP SUPP


SAP AG Cookbook IDE Page 79 of 153

Cookbook
Intercompany Data Exchange



Customizing:
You define the proposal for the non-billable service in Customizing for Intercompany
Data Exchange under Process Management Enrollment Services Based on
Operational Area Define Service Types.

Grid Own
service
provider
Enrollment
type
Service
type
Third
party
service
provider
Payment
class
Optional
service
G004 SUPP 0001 GRID GRID04

2. Execute move-in
Select the installation with the Grid service type.
You must make the following entries in the deregulation fields in the contract:

Contract Service provider Billing service
provider
Payment class
Supplier SUPP SUPP

The Deregulation tab page in the move-in transaction must contain the following entries.
You can also enter other fields for the service in this tab page.

Service Service
type
Service provider Payment class
Distributor GRID GRID04


Example 5: Supplier and Distributor in One System

Two contracts are to be created in the suppliers system, one for the supplier and one for the
distributor. The supplier acts as billing agent and is therefore the contract partner who is in direct
contact with the end customer.
Both service providers must be defined as service providers managed in own system. This means
you must select the field Service Provider is Managed in Own System for these service providers in
the Customizing settings for Intercompany Data Exchange under Service Provider Define Service
Providers.

1. Preparation
You must make the following entries in the deregulation fields for the installations:

Installation Service type Billing service provider
Supplier SUPP SUPP
Distributor GRID GRID05 or SUPP

Customizing:
NB services are not required, so you do not need to make any entries in the proposal table for
NB services.




SAP AG Cookbook IDE Page 80 of 153

Cookbook
Intercompany Data Exchange


2. Execute move-in
Select the installation with the Delivery service type and the installation with the Grid
service type.
You must make the following entries in the deregulation fields in the contracts:

Contract Service provider Invoicing service
provider
Payment
class
Supplier SUPP SUPP
Distributor GRID05 SUPP

The Deregulation tab page in the move-in transaction should remain blank.


5.1.1.4 Automatic Enrollment
The following diagram of a switch from the new suppliers perspective indicates a number of
processing steps.

New
supplier
Former
supplier
Distributor
Customer
Transmission
company
Supply request
Notice
Confirmation of notice
Notification of change of supplier (list of customer switches/new
customer enrollments)
Confirmation of change of supplier
(load profile/group allocation, annual energy amount)
Customer switch list
Register changed schedules
Final invoice
Meter values
Determine meter reading
Meter values
Register changed schedules
Greeting


SAP AG Cookbook IDE Page 81 of 153

Cookbook
Intercompany Data Exchange



The following processing steps are dealt with here (highlighted in the diagram):
1. Enter data on customer/point of delivery (CRM or SD)
a. Product selection
b. Master data generator
Create part of master data (business partner and so on)
2. Process of enrollment per point of delivery
a. Determine master data template for product
b. Communication
Give notice to former supplier
Await confirmation from former supplier
List of customer switches to distributor
Await confirmation from distributor
c. Master data generator
Create technical master data and execute customer move-in for switch date

The following diagram illustrates the basic procedure involved in automatic enrollment.
Master data template
with automatic
move-in
Contract
NB service
Enrollment
workflow
Master data Customizing
Default
contracts
NB services
Installation
Master data
generator
IDE
communication
Determine master data
template parameters
Workflow
data
Parameters


Automatic enrollment takes place as follows:
1. Determine scenario
2. Choose suitable master data template
3. Perform necessary IDE communication
4. Create master data
5. Perform customer move-in
When you do this, the system determines the proposals of NB services and contracts from the
proposal tables.

SAP AG Cookbook IDE Page 82 of 153

Cookbook
Intercompany Data Exchange



The following sections describe the alternatives for automatic enrollment:
The workflow template used by the mySAP SD component.
Instructions for a workflow that uses the mySAP CRM component.
The last section describes the use of the master data generator and describes how to create suitable
master data templates that can be used by all the alternative processes described.

Using the mySAP SD Component
In the following examples, the workflow template for SD enrollment uses the proposal procedure
based on service provider relationships. The operational area and the NB services are determined as
described for the manual process under 5.1.1.2 (Services Based on Operational Area).

You define the proposal for the contracts in Customizing for Intercompany Data Exchange under
Process Management Enrollment Services Based on Operational Area Define Process
Control. This table is used in the workflow template. The workflow templates are as follows:

Task
Description
WS20500140 ISUProdCRM CRM management for utility products
WS20500138 ISUIdeEnrCom IS-U: IDE enrollment communication

Note
The workflow templates for the SD component and the accompanying Customizing settings
were specially developed for Release 4.62 because integration with mySAP CRM was not
possible at that point. As of Release 4.63, CRM integration is possible, so that development of
the SD strategy has ended and implementation of this strategy is no longer recommended
from 4.63 onwards.
For more information, see the SAP Service Marketplace http://service.sap.com. Choose Enter
now and log on with your user name and password. Then choose Solution Details Industry
Solutions mySAP Utilities Media Center IS-U/CCS Core Components Cookbooks
IS-U Sales Processing on the SD-Platform

The examples of the scenarios correspond to those in section 5.1.1.2 (Services Based on
Operational Area). The proposals for the contracts are determined from the Customizing table
Determine Process Control and the required master data template is in turn determined from
these entries. Parameters for the master data template must be entered in the fields for the
installations and contracts.

Using the mySAP CRM Component
In the following examples, this alternative uses the proposal procedure based on the service provider
relationship. The grid is determined as described in the manual process under 5.1.1.3 (Services
Based on Service Provider Relationship).
The examples first describe the CRM-IS-U integration concept:
A replication mechanism ensures that IS-U master data that is relevant for CRM is
represented by data in the CRM System and vice versa. For example, an IS-U contract
corresponds to a contract item in the CRM System.
A CRM product in the CRM System is mapped to one master data template in the IS-U
System.




SAP AG Cookbook IDE Page 83 of 153

Cookbook
Intercompany Data Exchange


If enrollment is initiated in the CRM System, processing takes place as follows:
1. Business partner data, address data and technical data such as the connection object,
premise and point of delivery are recorded in the CRM System. To create this master data,
the replication mechanism starts the master data generator in the IS-U System with a
template belonging to the type CRMPARTNERTECH.
2. The sale of a utility product is recorded in CRM and creates a new contract item in the CRM
System. This triggers the master data generator in the IS-U System during replication.
3. Before the master data template (CRMNEWCONTRACT) is executed, the system calls a
BADI method (BADI definition EIDE_CRM, interface IF_EX_EIDE_CRM, method
IDE_PROCESS_NECESSARY), which determines whether or not IDE communication is
required.
a. If communication is required, the event IDECallNecessary is triggered for the BOR
object type ISUCRMCNCT (ISU-CRM Connector), so as to start an IDE workflow, and
the master data generator terminates without creating data.
b. If communication is not required, the master data template is executed and the
master data is created.
4. The IDE workflow manages communication and determines whether enrollment must be
executed. The IDE workflow also sets a status parameter in the workflow container indicating
that the IDE workflow is currently running.
a. If enrollment is to be executed, the workflow calls the master data generator again.
This is done by a method that calls the function module
ISU_PRODUCT_IMPLEMENT in a similar way to the method IsuProductImplement of
BOR object type ISUPRODUCT in the sample workflow for mySAP SD.
Internally, the master data generator calls the BADI method
IDE_PROCESS_NECESSARY again. The status parameter in the container indicates
to the method that the IDE workflow is running, so that it does not need to be
triggered.
The workflow must transport the data required for execution by the master data
generator in the container. It is also possible to change the date in the parameters for
the master data template, for example, if the move-in date changes, before the
master data generator is called.
b. If enrollment is not to take place, the workflow must call the method
ContractStatusChange for the BOR object type ISUCRMCNCT (ISU-CRM Connector)
so that the CRM System is informed of the rejection and can cancel the contract item
again.

SAP AG Cookbook IDE Page 84 of 153

Cookbook
Intercompany Data Exchange



The following diagram illustrates IS-U on the left hand side and the CRM System on the right and
displays the steps described above:

IDE Workflow
MDG
call method:
cancel VPOS
CRM ISU
create master data
IDE communication
[cancel]
create VPOS in CRM
BADI call for IDE
[no IDE]
[IDE]
trigger IDE workflow
receive IDoc
send IDoc
call MDG
[proceed]
cancel VPOS in CRM


Please note the following with regard to this procedure:
The master data generator only calls the BADI method described when processing a CRM
product.
If the scenario requires several contracts, the IDE workflow may need to access the master
data generator several times with template category CRMNEWCONTRACT. The replication
mechanism then creates further contract items automatically in the CRM System.

SAP AG Cookbook IDE Page 85 of 153

Cookbook
Intercompany Data Exchange


The only status available for the contract item in the CRM System is distributed. This status
indicates that the object has been inserted in the queue for the IS-U System but does not
indicate that replication in IS-U was successful.
If the IDE workflow does not send a rejection or create the contracts, the status of the data in
CRM is not consistent with that in IS-U.
You can maintain the proposals for billable services (contracts) in Customizing for
Intercompany Data Exchange under Process Management Enrollment Services Based
on Service Provider Relationships. You must implement these proposals yourself in the IDE
workflow to ensure that they are used.

Master Data Generator
The master data generator is used to create the technical and business master data for the new
customer and to execute move-in. To do this, you must access the master data generator with a
suitable master data template, in which you must enter the necessary parameters.
In the workflow, the master data generator is started by a method call. The parameters for the
master data template must be available in the workflow container.

The template categories available for the enrollment process are:
NEWCUSTPOD Enrollment with separate point of delivery
CRMNEWCONTRACT Enrollment linked to mySAP CRM

The following sections describe the nodes and fields of these master data template categories, which
are particularly important in connection with enrollment.

Note
For a detailed description on how to use master data templates, see the SAP Service
Marketplace http://service.sap.com. Choose Enter now and log on with your user name and
password. Then choose Solution Details Industry Solutions mySAP Utilities Media
Center IS-U/CCS Core Components Cookbooks Master Data Templates.

Template Category NEWCUSTPOD
You can use this template category to create master data on a new customer in the system and
execute move-in. The template category includes the following master data objects:
Business partner
Device information record
Connection object
Address for connection object
Device location
Premise
Point of delivery
NB services
Installation
Contracts created by move-in








SAP AG Cookbook IDE Page 86 of 153

Cookbook
Intercompany Data Exchange


The following illustrates the structure of the template category:



The nodes highlighted are described with their attributes in greater detail at a later point. The
recommended evaluation types of the attributes are underscored.
Point of delivery (POD)
A point of delivery can be created independently of the installation. The link to the installation is
set up in the installation node when the internal key of the point of delivery created here is
entered in the point of delivery node.

SAP AG Cookbook IDE Page 87 of 153

Cookbook
Intercompany Data Exchange



The attributes are as follows:

Name Description Evaluation type of
attribute
Comment
DATEFROM
required
From-date Parameter,
constant or virtual
The start date of the time slices for the point
of delivery ID and the grid allocation. The
point of delivery can only be identified by its ID
from this point in time. Required attribute, for
example move-in date.
EXT_UI Point of delivery
ID
Parameter,
constant, virtual or
do not change
There should always be a point of delivery ID
in the deregulated market. It must correspond
to the default structure category or to the
structure category specified in the attribute
UISTRUTYP.
UISTRUTYP Structure
category of point
of delivery ID
Parameter,
constant, virtual or
do not change
Need only be specified if the point of delivery
ID differs from the default structure category.
VSTELLE Premise Key reference Link to the higher-level node for the premise.
This internal allocation, which cannot be
maintained in a transaction, is required in the
CRM context.
GRID_ID Grid Parameter,
constant, virtual or
do not change
You must specify the grid if the point of
delivery ID EXT_UI is specified in this node.
INT_UI
required
Internal key for
point of delivery
Identifying constant Required attribute, which is returned as a key
when a point of delivery is created.

Services
You can use this node to create NB services for the point of delivery independently of move-in. If
move-in is executed later using the node Move-in, the existing services are not created again. In
accordance with the global setting for determining proposals for services, you must either
activate the node Services Based on Service Provider Relationships or Services Based on
Operational Area (see 5.1.1.3 or 5.1.1.2).

When the node is executed, it creates all the services that can be determined from the proposal
tables using the attributes that serve as selection criteria for proposals.
This means the first node of the Services type can create several objects at once.

Caution
The node for the services behaves differently from other nodes in the master data templates.

Each subsequent node of the Services type can then be used to change one service identified by
the attributes INT_UI, SERVICE_START and SERVICE.
Before you can make changes of this kind to several services, you must multiply the node. The
attribute VERTRAG must not be blank in the repetition node; you could, for example, enter the
start date parameter here. This is the only way for the node to recognize that you are changing
the services created with the first node and not trying to create further services.


SAP AG Cookbook IDE Page 88 of 153

Cookbook
Intercompany Data Exchange



Note
Changes to the default values for a service can also be made in the first node. It is even possible to
transfer a service provider for whose service no service provider specified in the proposal table.
Since all subsequent service nodes can only make changes to the services created by the first node,
the service providers for all other services in the proposal table must not be blank.

Services based on service provider relationship
The attributes are as follows:
Name Description Evaluation type
of attribute
Comment
VERTRAG Key of point
of delivery
service (same
as contract)
Constant for first
node.
Parameter, for
example, move-
in date, for the
subsequent
nodes.
Must be left blank for the first node
so that new services are created.
In all subsequent nodes, which make
changes to the services created, you
must specify a value of your choice.

INT_UI Internal key
of point of
delivery
Key reference Identifier attribute for changes.
Point of delivery for which the
services are to be created. Should be
copied from the higher level node
Point of delivery.
SERVICE_START Start date of
point of
delivery
service
Parameter,
constant or
virtual
Identifier attribute for changes.
You must always specify a start date.
SERVICE Service type Parameter,
constant, virtual
or do not change

Identifier attribute for changes.
If you want to overwrite the default
values for one of the services, you
must specify the relevant service
type here.
SERVICEID Service
provider
Parameter,
constant, virtual
or do not change

Allows an entry to be made in this
field for the service determined from
the identifier attributes.
SRVPRVREF External
contract
number for
service
provider
Parameter,
constant, virtual
or do not change

Allows an entry to be made in this
field for the service determined from
the identifier attributes.

SERVPROV_PAY Payment
class
Parameter,
constant, virtual
or do not change
Allows an entry to be made in this
field for the service determined from
the identifier attributes.
SPARTE Division Parameter,
constant, virtual
You must specify the division so that
the system only creates proposals for
service types belonging to this
division.
STARTOBJTYPE Object type Parameter,
constant, virtual
or do not change
Allows an entry to be made in this
field for the service determined from
the identifier attributes.

SAP AG Cookbook IDE Page 89 of 153

Cookbook
Intercompany Data Exchange


Name Description Evaluation type
of attribute
Comment
STARTOBJKEY Document
number
Parameter,
constant, virtual
or do not change
Allows an entry to be made in this
field for the service determined from
the identifier attributes.
ENDOBJTYPE Object type Parameter,
constant, virtual
or do not change
Allows an entry to be made in this
field for the service determined from
the identifier attributes.
ENDOBJKEY Document
number
Parameter,
constant, virtual
or do not change
Allows an entry to be made in this
field for the service determined from
the identifier attributes.
GRID_ID Grid Parameter,
constant, virtual
or do not change
Selection criterion for proposals.
If this is not specified, the
determination procedure described in
5.1.1.3 is run.
KTOKL Contract
account class
Parameter,
constant, virtual
or do not change
Selection criterion for proposals.
Must be specified so that the service
proposals can be determined.
SERVICE_PROV Own service
provider
Parameter,
constant, virtual
or do not change
Selection criterion for proposals.
Must be specified so that the service
proposals can be determined.
POLR Provider of
last resort
Parameter,
constant, virtual
or do not change
Selection criterion for proposals.
Must be specified so that the service
proposals can be determined.


Services based on operational area
The attributes are as follows:

Name Description Evaluation type
of attribute
Comment
VERTRAG Key of point
of delivery
service
(same as
contract)
Constant for first
node.
Parameter, for
example, move-in
date, for the
subsequent
nodes.
Must be left blank for the first node
so that new services are created.
In all subsequent nodes, which make
changes to the services created, you
must specify a value of your choice.
INT_UI Internal key
of point of
delivery
Key reference Identifier attribute for changes.
Point of delivery for which the
services are to be created. Should
be copied from the higher level node
Point of delivery.
SERVICE_START Start date of
point of
delivery
service
Parameter,
constant or virtual
Identifier attribute for changes.
You must always specify a start
date.
SERVICE Service type Parameter,
constant, virtual
or do not change

Identifier attribute for changes.
If you want to overwrite the default
values for one of the services, you
must specify the relevant service

SAP AG Cookbook IDE Page 90 of 153

Cookbook
Intercompany Data Exchange


Name Description Evaluation type
of attribute
Comment
type here.
SERVICEID Service
provider
Parameter,
constant, virtual
or do not change

Allows an entry to be made in this
field for the service determined from
the identifier attributes.
SRVPRVREF External
contract
number for
service
provider
Parameter,
constant, virtual
or do not change

Allows an entry to be made in this
field for the service determined from
the identifier attributes.

SERVPROV_PAY Payment
class
Parameter,
constant, virtual
or do not change

Allows an entry to be made in this
field for the service determined from
the identifier attributes.
SPARTE Division Parameter,
constant, virtual

You must specify the division so that
the system only creates proposals
for service types belonging to this
division.
STARTOBJTYPE Object type Parameter,
constant, virtual
or do not change

Allows an entry to be made in this
field for the service determined from
the identifier attributes.
STARTOBJKEY Document
number
Parameter,
constant, virtual
or do not change

Allows an entry to be made in this
field for the service determined from
the identifier attributes.
ENDOBJTYPE Object type Parameter,
constant, virtual
or do not change

Allows an entry to be made in this
field for the service determined from
the identifier attributes.
ENDOBJKEY Document
number
Parameter,
constant, virtual
or do not change

Allows an entry to be made in this
field for the service determined from
the identifier attributes.
OPAREA Operational
area
Parameter,
constant, virtual
or do not change

Selection criterion for proposals.
If this is not specified, the
determination procedure described
in 5.1.1.2 is run.


SAP AG Cookbook IDE Page 91 of 153

Cookbook
Intercompany Data Exchange



Point of delivery for installation (POINT_OF_DELIVERY)
The point of delivery node in the installation node is used to specify the connection to the point of
delivery for the installation.
Name Description Evaluation type
of attribute
Comment
DATEFROM
required
From-date Parameter,
constant or virtual
The start date of the time slices for the
allocation of the point of delivery to the
installation and the point of delivery ID if
it is specified in EXT_UI.
EXT_UI Point of
delivery ID
Parameter,
constant, virtual
or do not change

You do not need to make an entry in this
field if you do not require a point of
delivery ID or if it was already specified in
the higher-level node.
UISTRUTYP Structure
category of
point of
delivery ID
Parameter,
constant, virtual
or do not change

You do not need to make an entry in this
field if you do not require a point of
delivery ID, or if a different structure
category was already specified in the
Point of delivery higher-level node.
INT_UI Internal key for
point of
delivery
Key reference Key of the point of delivery from the Point
of delivery higher-level node. The
installation is allocated to this point of
delivery.

GRID_ID Grid Parameter,
constant, virtual
or do not change
You must specify the grid if the point of
delivery ID EXT_UI is specified in this
node.

Template Category CRMNEWCONTRACT
This template category is designed for integration with the mySAP CRM component and you must
use it if you use mySAP CRM. The template category works on the assumption that certain master
data objects have already been created in the system, for example when using master data
templates that belong to the category CRMPARTNERTECH. In the category CRMPARTNERTECH,
the Point of delivery node (POD) is filled as described for the template category NEWCUSTPOD.
If you are using a template that belongs to the category CRMNEWCONTRACT to execute
enrollment, you should have created the following master data objects beforehand:
Business partner
Connection object
Premise
Point of delivery
The keys of these objects are used to identify the master data construct. The template category
CRMNEWCONTRACT can create the following data objects:
Device information record
NB services
Installation
Contracts created by move-in
The template of this category also references the CRM product. This means that when the contract
is replicated to the CRM System, a contract item with the appropriate product data is created.

SAP AG Cookbook IDE Page 92 of 153

Cookbook
Intercompany Data Exchange



The following illustrates the structure of the template category CRMNEWCONTRACT:



The nodes highlighted are described in detail below, together with their parameters.
Point of delivery (POD)
This node only serves to identify an existing point of delivery, which is allocated NB services or
linked to an installation by the subsequent node for services.


SAP AG Cookbook IDE Page 93 of 153

Cookbook
Intercompany Data Exchange



The attributes are as follows:
Name Description Evaluation type
of attribute
Comment
EXT_UI
Point of delivery
ID
Parameter,
constant, virtual
or do not change

No entry required.


INT_UI Internal key of
point of delivery
Parameter,
constant or
virtual
Identifies the existing point of delivery using
the internal key.



Services
You can use this node to create services for the point of delivery independently of move-in. The
node is used in the same way as for the template category NEWCUSTPOD.

Point of delivery of installation (POINT_OF_DELIVERY)
The point of delivery node in the installation node is used to create the link between the
installation and the point of delivery. The node is used in the same way as for the template
category NEWCUSTPOD.


SAP AG Cookbook IDE Page 94 of 153

Cookbook
Intercompany Data Exchange



5.1.2 Former Suppliers Perspective
A change of supplier means that the former supplier loses a customer. In the deregulated market,
the process is usually triggered by an incoming message.
New
supplier
Former
supplier
Distributor
Customer
Transmission
company
Supply request
Notice
Confirmation of notice
Notification of change of supplier (list of customer switches/new
customer enrollments)
Confirmation of change of supplier
(load profile/group allocation, annual energy amount)
Customer switch list
Register changed schedules
Final invoice
Meter values
Determine meter reading
Meter values
Register changed schedules
Greeting

The diagram of the change of supplier from the former suppliers point of view shows the following
processing steps:

1. Receipt of notice from new supplier
2. Process for loss of customer at point of delivery
Check admissibility of notice
Communication
Send rejection/confirmation to new supplier
Await customer switch list from distributor,
processing with error workflow if not received
End of contract, customer move-out on change date
Communication
Await consumption values from distributor,
processing with error workflow if not received
Final invoice for customer

The templates currently available are listed in the appendix 12.3.1 or 12.5.


SAP AG Cookbook IDE Page 95 of 153

Cookbook
Intercompany Data Exchange


5.1.3 Distributors Perspective
For the distributor, the change of supplier means that they must communicate with a new supplier in
future. The master data must be modified accordingly. If the deregulation scenario between the
distributor and the new supplier is different, the number of contracts and NB services may change.
For this reason, you may need to create further installations. The distributor may also need to inform
other parties of the change, for example a transmission company, a meter reading service or the
former supplier.
In the deregulated market, the process is usually triggered by an incoming message.
New
supplier
Former
supplier
Distributor
Customer
Transmission
company
Supply request
Notice
Confirmation of notice
Notification of change of supplier (list of customer switches/new
customer enrollments)
Confirmation of change of supplier
(load/group allocation, annual energy amount)
Customer switch list
Register changed schedules
Final invoice
Meter values
Determine meter reading
Meter values
Register changed schedules
Greeting


The diagram of the change of supplier from the distributors point of view shows the following
processing steps:

1. The process begins when the new customer enrollment list is received from the new supplier. This
takes place:
a. automatically if the information is received via IDoc
b. manually from the CIC if the information is received via the traditional channel
2. The supplier change process at a point of delivery is started. This process comprises the
following steps:
a. Check completeness/admissibility of change
b. Communication
Send rejection/confirmation to new supplier
Send customer switch list to previous supplier

SAP AG Cookbook IDE Page 96 of 153

Cookbook
Intercompany Data Exchange


c. Modify master data
End non-billable service/former suppliers client
Start non-billable service/contract for new supplier
Create meter reading order at start of delivery
3. Subsequent processing
a. Receipt of meter reading at start of delivery
b. Communication
If applicable, final invoice to former supplier for grid usage
Transfer consumption values to former and new suppliers

SAP AG Cookbook IDE Page 97 of 153

Cookbook
Intercompany Data Exchange



The following diagram illustrates a possible workflow that performs steps 1 and 2.


Service change
workflow
Modify
master data
[Confirmation]
Workflow
data
Point of delivery
Old service
New service
Switch date
Determine
current scenario
Determine
desired scenario
Sub-workflow
IDE communication
rejection / confirmation
[Rejection]
Contract
NB Service
Installation
Scenario
Workflow started
automatically by IDoc
manually by CIC / front office
Check completeness/
admissibility
Contract
NB Service
Installation
Default
contracts
NB services
Sub-workflow
IDE communication
Customer switch list


At present, no templates are delivered for this process. For this reason, this documentation provides
a description of a process using the function modules for a change of service and scenario.

SAP AG Cookbook IDE Page 98 of 153

Cookbook
Intercompany Data Exchange


5.1.3.1 Function Modules for Change of Service and Scenario
Scenario Determination with ISU_IDE_SZENARIO
The function module ISU_IDE_SZENARIO determines the current scenario for a point of delivery by
determining the contracts and NB services and interpreting their field contents. It identifies a valid
scenario using the BAdI method CL_EX_ISU_IDE_SZENARIO -> SZENARIO_DEFINE, which uses
the function module ISU_IDE_SZENARIO_DEFINE in the standard implementation. This function
module contains the scenarios defined by SAP. Other customer-specific scenarios can be supported
if you overwrite this method. The scenarios supported at present are listed in the appendix 12.3.1.
Starting from the point of delivery, the module reads all NB services and all the contracts according
to the installations allocated, and so determines all the services for the point of delivery.
The input parameters are as follows:
Point of delivery (internal key or point of delivery ID), contract or installation
If you specify the contract or installation, the system first determines the point of delivery for
which the data scenario is then read.
Key date on which the data scenario is read
The results tables are as follows:
T_IDE_SZENARIO contains a list of relationships between your own service providers and all
other service providers who perform services at the point of delivery. Information on
relationships between two service providers is displayed in each line. If the related service
providers are a distributor and a supplier, the scenario identified is listed in the last column.
T_ALL_SERVICES contains a list of all services (contracts and NB services) with database
keys and further fields.
T_IDE_SERVICE contains all the services and the important fields for deregulation in a
compact form.

Determining Proposals with ISU_IDE_ENROLL_DEFAULT
Function module ISU_IDE_ENROLL_DEFAULT determines proposals for contracts and NB services
from Customizing. During processing, the system also checks for a valid scenario that uses the BAdI
method CL_EX_ISU_IDE_SZENARIO -> SZENARIO_DEFINE in the same way as
ISU_IDE_SZENARIO.
The results of proposal determination are as follows:
1. Proposals of own contracts, which must be created for your own service providers.
2. Proposals of third party contracts, which must be created in your system for another service
provider
3. Proposals of NB services that have to be created
The input parameters form the selection criterion for the proposals (see also 5.1.1.3). The
parameters are as follows:
Contract account or contract account class
Own service provider
Grid
An indicator denoting enrollment in the role of provider of last resort
Table T_SERVPROV_OTHER is used to transfer the other service providers who are used
for selection in the proposal tables. If several service providers are specified here, all the
proposals determined are combined. This does not apply to proposals for contracts for the
own service provider. These are determined only from the other service provider from table
T_SERVPROV_OTHER, for whom the indicator RELEVANT is selected.
You can specify alternative service providers and field entries in table T_IDE_SERVICE.
These values overwrite the default values. However, the entries must be accepted by the
scenario check.

SAP AG Cookbook IDE Page 99 of 153

Cookbook
Intercompany Data Exchange


The proposal results for own, third party contracts and NB services are returned together in table
T_IDE_SERVICE:
T_IDE_SERVICE contains all services (contracts and NB services) that must be created in
compact form with the fields important for deregulation.
The scenario is delivered as a further result in T_IDE_SZENARIO:
T_IDE_SZENARIO can be interpreted in the same way as ISU_IDE_SZENARIO. However,
in this case the system does not read a current data scenario but analyzed the proposed data
scenario.
Creating the Action List with ISU_SERVICE_SZENARIO_SWITCH
The main input parameters for function module ISU_SERVICE_SZENARIO_SWITCH are two lists of
services (contracts and NB services).
1. The actual status of the services, for example as determined by ISU_IDE_SZENARIO.
2. The planned status of the services, for example as proposed by
ISU_IDE_ENROLL_DEFAULT.
The function now generates a list of statements that can convert the actual status to the planned
status. Like ISU_IDE_ENROLL_DEFAULT, this function also uses the BAdI method
CL_EX_ISU_IDE_SZENARIO-> SZENARIO_DEFINE to exclude invalid scenarios.
The input parameters are as follows:
Table T_SERVICE_OLD containing the actual status of the services
Table T_SERVICE_NEW containing the planned status of the services
Table T_ALL_SERVICES containing the current services with their keys as identified by
ISU_IDE_SZENARIO
The result is the statement list:
Table T_SWITCH_ACTION contains all the actions (Create, Change and Delete) that must
be performed in order to convert the actual status to the planned status. The data objects
supported and the accompanying fields are listed here:

Object
type
Type text Data fields Field name
Service provider SERVICEID
Billing service provider INVOICING_PARTY
Contract ISUCONTRCT
Payment class SERVPROV_PAY
Service provider SERVICEID NB
services
ISUNBSERVC
Payment class SERVPROV_PAY
Service type SERVICE Installation INSTLN
Invoicing service provider BILLING_PARTY

Executing the Action List with ISU_SERVICE_SWITCH_EXECUTE
Function module ISU_SERVICE_ SWITCH_EXECUTE can now execute the statement list created
by ISU_SERVICE_SZENARIO_SWITCH to make the changes to the data. This function executes
service changes or contract changes using move-out and move-in depending on whether NB
services or contracts are changed. Since this may necessitate the creation of installations or
contracts, the function uses the following BAdI methods to enter customer-specific data in the fields
in the new installations and contracts:
ISU_SZENARIO_SWITCH->NEW_INST_OBJ_CHANGE
ISU_SZENARIO_SWITCH->NEW_CONTRACT_CHANGE

The parameters for ISU_SERVICE_ SWITCH_EXECUTE are as follows:
Point of delivery
Division
Move-out date; tomorrows date is used internally as the move-in date

SAP AG Cookbook IDE Page 100 of 153

Cookbook
Intercompany Data Exchange


The contract account is required when creating new contracts
The business partner is required when creating new contracts
Further contract data that must be entered for new contracts
Statement list for the changes
5.1.3.2 Contract Change
A supplier change can lead to a contract change. This section explains how the system handles
information and master data that is directly related to the contract.

The contract change reason Supplier change can be found in Customizing for the SAP Utilities
component under Customer Service Process Execution Move-In/Out Define Reasons for
Contract Change. The object has the following possible settings:
Transfer contract-related installation facts.
Transfer security deposits.
Transfer budget billing plan, the payment plan normally used in Europe. Transfer can only
take place if final invoicing does not take place for the old contract.
If invoicing takes place, the final invoice for the old contract.
Handling of open items.

Payment Plan
When a change of contract takes place due to a change of supplier, payment plans belonging to the
categories BBP (Budget Billing Plan) and AMB (Average Monthly Billing), which are used in the US,
must be copied from the contract that has been ended into the new contract. The copying process
and release of the difference amount/balance carryforward (Balance-Forward-Amount) takes place
during final invoicing for the contract being ended.
Whether or not the payment plan is copied depends on the way in which the payment plan category
is defined in Customizing for the SAP Utilities component under Invoicing Budget Billing Plan
Payment Plan Define Payment Plan Categories (AMB/BBP).

The category BBP payment plan is copied to the new contract with the corresponding due dates and
amounts. When this takes place, the start date of the payment plan is moved to the move-in date for
the new contract and due dates that are before this date are excluded from the copying process.
Before the payment plan can be copied, the following data in the new contract must match that in the
old contract:
Contract account
Payment plan data defined in the contract
Portion
If a manual history exists for the old contract, this is also copied. If data already exists for the manual
history for the new contract, this data is deleted beforehand.
Since a physical budget billing plan does not exist for payment plans of the category AMB, the
system only copies the manual history in this case, also deleting the history for the new contract if
this exists.
5.1.3.3 Procedure for Change Process
The change process is triggered by the receipt of an IDoc or can also be triggered manually from the
CIC. The following data, which can be taken from the incoming IDoc or from an input template, must
be known:
Point of delivery
Change date

SAP AG Cookbook IDE Page 101 of 153

Cookbook
Intercompany Data Exchange


New supplier
Former supplier

The change of supplier can take place as follows using the function modules described above:

1. Determine current scenario using ISU_IDE_SZENARIO
Parameters:
Point of delivery
Change date
Return:
Scenario list
List of current services
List of current services with keys

2. IDE communication implemented as a sub-workflow or a function module

3. Determine desired scenario using ISU_IDE_ENROLL_DEFAULT
Parameters:
Contract account class
Linked to the enrollment type by the BAdI
Own service provider
Grid
List of other service providers.
The service provider relevant for selecting the default values is marked.
List of services (preassignment)
Return:
List of desired services

4. Create list of actions using ISU_SERVICE_SZENARIO_SWITCH
Parameters:
List of current services
List of desired services
List of current services with keys
Return:
Action list

5. Process action list using ISU_SERVICE_SWITCH_EXECUTE
Parameters:
Action list

This description of the process is only one possible solution.


The templates currently available are listed in the appendix 12.3.1 or 12.5.






SAP AG Cookbook IDE Page 102 of 153

Cookbook
Intercompany Data Exchange


5.2 Service Notification
5.2.1 General
This process is based on requirements of the US State of Texas. The basic process flow is generally
valid. The Texan requirements are apparent, for the most part, in the specifications of the templates
for communication: the accompanying IDoc and the functions for data mapping are based on the
message formats EDI 650-01, EDI 650-02 and EDI 650-03.
The standard templates are only for the party requesting the service, in other words, they cover the
functions for sending service notifications and for processing confirmations of service notifications.
No functions are available for the recipient, the party who executes the service notification. You must
implement these functions yourself as part of the implementation project.

To simplify matters, the following sections are based on a typical scenario in which the requesting
party is a supplier and the executing party is a distributor.
5.2.2 Process
From the suppliers perspective, the process includes the following steps:
1. Customer calls the suppliers Customer Service department and requests a service (meter
defective).
2. Supplier sends the distributor the service notification as an electronic message.
3. Distributor sends the supplier a confirmation.
a. Notification completed successfully
b. Notification rejected
c. Notification could not be completed
4. If the customer calls in the meantime and reports that the problem has been solved, the supplier
informs the distributor of this.
5.2.3 Implementation
Communication between the supplier and the distributor is based on the service notification. The
service notification is created in the suppliers system by a front office process and sent to the
distributor via IDoc. If the distributor sends the supplier a service confirmation, the service notification
is automatically refreshed in the suppliers system.
5.2.3.1 Record Service Notification
The service requested by the customer can be recorded using a front office process (FOP).
You can use the front office process (FOP) SNOT650 to create service notifications.
FOP SNOT650 comprises:
Front office process SNOT650S
Editor step SNOT6501
Editor step SNOT6502

The FOP is integrated in the data environment configuration ISU (transaction ENVD). This means
that you can start the FOP by clicking with the right mouse button on the installation, premise or
device. If you start the FOP by clicking on the installation or premise, the connection object is taken
as the reference object for the service notification. If you start it by clicking on the device, the
device/equipment is taken as the reference object.
The FOP gathers the data required in order to create a service notification.


SAP AG Cookbook IDE Page 103 of 153

Cookbook
Intercompany Data Exchange


The FOP is processed as follows:
1. Selection of service code according to codes in code group ISU650SO (catalog category 8)
You maintain the catalogs and code groups in Customizing under Plant Maintenance and
Customer Service -> Maintenance and Service Processing -> Maintenance and Service
Notifications -> Notification Creation -> Notification Content -> Maintain Catalogs.
You must not change the notification codes while you are still using the standard SAP
function modules in your process.
The code groups are defined in the include IEIDESREQ_CODEGROUPS_CODES.
2. Additional information on notification creation
You can specify additional information (for example, planned start date, device information
record, long text) or specify rules on the admissibility of weekend, night and public holiday
work. An item is created in the service notification for each permission. The codes for the
permission are taken from code group ISU650YN (catalog category C).
3. Lock installation
You can specify whether or not an installation can be locked. An item is created for this
purpose in the service notification. The codes are taken from code group ISU650SU (catalog
category 8).
4. Information on the temporary contact person
In addition to the contract partner for whom the service is requested, you can also enter data
on a temporary contact person. These entries include a one-time customer as a partner in
the service notification. To include a one-time customer in the service notification, you must
specify a partner role with an account group for one-time customers. The partner role is
specified in the FOP as a constant in the data flow for method
ISUSMNOTIF.ADDONETIMEPARTNER in step 80. The number of the one-time customer
must also be specified there.
5. The FOP creates a service notification that contains the data required for creating the IDoc
that is sent from the requesting party to the receiving (executing) party. The installation or
device information record are linked to the service notification by means of an object link.

You can display the link in the service notification by means of the menu path Extras -> Documents
for notification -> Utilities industry document flow. The point of delivery can be determined from the
installation during runtime.
The service notification is created using a notification code. The FOP creates the notification code by
linking the literal SO with the code chosen in step 1 from code group ISU650SO.
Example:
If you choose code 13 (Investigation) as the service category, the FOP attempts to create the service
notification using code SO13.
5.2.3.2 Communication
The system uses an IDoc of the category ISU_MAINTENANCE_SERVICE_ORDER as a template
for communication.

The supplier sends the distributor an IDoc:
to request a service
to cancel a service request sent previously

The distributor sends an IDoc to the supplier:
to confirm that the service has been performed successfully
to reject a service requested
to cancel a service requested


SAP AG Cookbook IDE Page 104 of 153

Cookbook
Intercompany Data Exchange


SND_SRVREQ is used as the trigger communication event for sending the service request from the
suppliers system. Start report RESERVICEREQUEST_DEREG. Service notifications are selected in
the system based on the criteria you specify. An IDoc of the category
ISU_MAINTENANCE_SERVICE_ORDER is then sent to the distributor for each service notification.

An incoming IDoc of the category ISU_MAINTENANCE_SERVICE_ORDER triggers the event
REC_SRVREQ. The IDoc is then analyzed in order to determine one of the three business
transactions described above.
5.2.3.3 Processing the Confirmation
The service notification is refreshed in the requesting partys system according to the business
transaction. The service notification is completed in all cases.
The system also uses codes in code groups ISU6501P and ISU6507G to note the reason why a
service was rejected or not performed as an item in the service notification.
You can maintain the catalogs and code groups in Customizing under Plant Maintenance and
Customer Service -> Maintenance and Service Processing -> Maintenance and Service Notifications
-> Notification Creation -> Notification Content -> Maintain Catalogs.
You must not change the notification codes while you are still using the standard SAP function
modules in your process.

All the codes are defined in the include INCLUDE IEIDESREQ_CODEGROUPS_CODES.

5.3 Master Data Change
If certain pieces of master data change, these changes must be communicated to other service
providers involved. The data involved - in other words, which master data objects and fields in the IS-
U system are affected - is determined by the rules of the deregulated market in question.

Caution
Changes of service provider or payment class in contracts or NB services must be recorded
as a change process, since a contract change or scenario change may become necessary.
The change of supplier is described in section 5.1. These changes are not classified as
master data changes.
5.3.1 Outbound
Communication events are triggered immediately when changes are made to the following master
data objects:
Business partner
Contract account
Contract, with a further distinction between several different events:
End contract
Cancel end of contract
Change fields in contract
NB service
Connection object
Installation
Installation facts
Load profile
Replacement

SAP AG Cookbook IDE Page 105 of 153

Cookbook
Intercompany Data Exchange



The events and the trigger function modules are listed in the appendix 12.3.1.The corresponding
processing modules that are defined for the individual events in communication control are used to
convert the change data to the basic IDoc format and send it. Most master data changes are
processed using the template ISU_COMPR_REQ_CHANGE.

5.3.2 Inbound
Inbound IDocs containing information on master data changes are received by an event module
(template ISU_COMEV_IDOC_ISU_REQUEST, see appendix 12.5), which triggers the
communication event REQ_CHANGE. The processing module (template
ISU_COMPR_REQ_DATA_CHANGE) must then interpret the IDoc and change the relevant IS-U
master data objects.



SAP AG Cookbook IDE Page 106 of 153

Cookbook
Intercompany Data Exchange


6 Communication Control
6.1 Basics of Communication
The following graphic describes the procedure for electronic communication using IDocs, based on
an example of the process flow for data transfer between two customer information systems.

IS-U
system
SAP
Business
Connector
or third
party
admin.
IDoc
Data in
appropriate
format
(e.g. ASCII)
CCS system
sender
CCS system
receiver
SAP BC or EDI
subsystem
EDI subsystem
receiver
Transmission
network
Data in
appropriate
format
(e.g. ASCII)
X400, VAN,
leased line
and so on
Data in
standard
format
(e.g. EDIFACT,
ANSI X.12)
System limitation
Data in
standard
format
(e.g. EDIFACT,
ANSI X.12)
System limitation


The sender extracts the data for transfer from their customer information system (IS-U) and writes it
to a data carrier in the appropriate format. In the SAP System, the format is an IDoc from the CA-EDI
component. An upstream system (SAP Business Connector or EDI subsystem) translates the data to
a standard format agreed on by the communication partners independently of the individual customer
information systems.
The upstream system also represents the interface with the transfer medium and therefore with the
system limitation.

On the recipient side, an upstream system also forms the interface at the system limitation. The
recipient expects to receive the message in standard format. This format is translated into the
appropriate format for the receiving customer information system and is then integrated in the
business processes that are mapped there.


SAP AG Cookbook IDE Page 107 of 153

Cookbook
Intercompany Data Exchange


EDI subsystems are supplied by third party administrators and connected to the SAP System by
means of a certified interface.

The process from data extraction from the IS-U system through creating the IDoc (outbound) and
processing an inbound IDoc is explained in greater detail in the following sections.
6.2 Basics of Communication Control
In the process of sending and receiving IDoc messages in IS-U, an application program (outbound
processing) or the IDoc system (inbound processing) calls an event module. This function module
determines a process module that performs the necessary activities. In outbound processing, these
activities primarily involve entering data in the IDoc, while in inbound processing the function module
processes the response to the message received.
In order to send and receive IDocs, the settings for the IDoc component must be set accordingly in
Customizing for the Basis components under Application Link Enabling (ALE) and the necessary
settings must be made in the SAP menu under Tools -> Business Communication -> IDoc Basis.
The partner type SP (IS-U service provider) has been created specially for Intercompany Data
Exchange in the SAP menu under Tools -> Business Communication -> IDoc Basis -> IDoc ->
Partner Profile.

The following activities in the Customizing settings for Intercompany Data Exchange control which
process module is called for a particular process in the IS-U system:
Define Control Parameters
Define Processing Events
Activate Processing Events
Define Function Modules for Processing Events
Define Communication Based on Service Types
Define Communication Based on Service Providers

The function of the individual activities in communication control is explained in the following.
6.2.1 Define Control Parameters
This activity can be found in Customizing for Intercompany Data Exchange under Basic Settings ->
Define Control Parameters.
This activity allows you to control which communication method is to be used. You must choose
between the following types of communication control:
Communication according to service type
Communication control based on service types is intended for a more stable deregulated market
in which communication standards do not vary in a particular distribution grid. The
communication standards are defined on the level of the service type.
Communication according to service provider
Communication based on service providers is intended for a deregulated market in which
communication standards can vary from one service provider to another. The communication
standards are defined at the level of the service provider, so that it is possible to make very
detailed specifications with regard to the type and format of communication with a service
provider.
Depending on the service determination method you choose, you must also make the necessary
settings under Process Management Enrollment.


SAP AG Cookbook IDE Page 108 of 153

Cookbook
Intercompany Data Exchange


Note
The communication method you choose here is used for all communication in the IS-U
System.
Sending and receiving schedules and load shapes is the one exception. This process always
takes place using the communication method Communication According to Service Provider,
even when the communication process specified is Communication According to Service Type.
The reason for this is that schedules and load shapes must also be sent to recipients who
cannot be identified as the service providers for a point of delivery service.

6.2.2 Define Processing Events
This activity can be found in Customizing for the SAP Utilities component under Tools -> System
Modifications -> User-Defined Enhancements for IDE -> Define Processing Events.

The activity contains the communication events predefined by SAP. In communication control, a
communication event stands for the business process. For example, REQ_ENROLL stands for an
inbound request for a change of supplier and CH_PARTNER stands for the change to the business
partner data, which must be communicated externally.
An event is defined either for outbound or inbound communication. You choose the direction in which
communication is to take place in this activity.

In this activity, you can also define further communication events in addition to the standard events
provided by SAP. These are defined for specific clients. You must create new entries in the customer
name range. Enhancing the communication events for outbound IDocs always involves modifying the
standard programs. In this case, please contact SAP.

Note
If continued processing is to take place for outbound communication, the events contained in
this activity must also be entered in the activity Activate Processing Events and the CE active
field must be selected in both activities.

6.2.3 Activate Processing Events
This activity can be found in Customizing for Intercompany Data Exchange under Communication
Control -> Activate Processing Events.

In this activity, you define which of the communication events are to be active for outbound
communication. The communication is only processed for activated events. This means that further
processing only takes place if an event from the Define Processing Events activity is also contained
in this activity and the CE active field is selected.
Note
Activating events is irrelevant in inbound communication.
For further information on process management for inbound communication, please see
section 6.4.

Whilst communication events are defined client-specifically, they are activated for all clients.


SAP AG Cookbook IDE Page 109 of 153

Cookbook
Intercompany Data Exchange


6.2.4 Define Function Modules for Processing Events
You can find this activity in Customizing for Intercompany Data Exchange under Communication
Control -> Define Function Modules for Processing Events.

The activity contains standard communication events supplied by SAP with the relevant function
modules. You must not change these entries.

You can also enter company-specific function modules for the relevant events in this activity. The
settings apply to all clients. New entries must be created in the customer name range.
The function modules you define as admissible in this activity are used in a subsequent step (under
Define Communication Based on Service Types or Define Communication Based on Service
Providers).

6.2.5 Define Communication Based on Service Types
You can find this activity in Customizing for Intercompany Data Exchange under Communication
Control -> Define Communication Based on Service Types.

In this activity, you define communication control. You specify which communication events you want
to use and which function module is to be used in which case.
The input help proposes the function modules you entered previously in the Define Function Modules
for Processing Events activity.

The settings in this activity are only taken into account if you specified the communication process
according to service types in the Define Control Parameters activity.
This activity is blank in the standard delivery. You must enter the communication events you require
in your business processes.
Two service types are specified. These are the service type from your own system and that of the
communication partner. You must define the relevant services for the point of delivery.

Outbound Processing
In outbound processing, the system first reads all the services for a point of delivery and thus the
corresponding service providers and service types.
The senders service type is determined from the services for which the corresponding service
provider is marked as a service provider managed in your own system. A service provider managed
in your own system is one for whom the Service provider field is managed in own system is selected
in the Define Service Provider activity.




SAP AG Cookbook IDE Page 110 of 153

Cookbook
Intercompany Data Exchange


Services to which the following applies are relevant for the recipients service type:
Services in which the service provider is not marked as a service provider managed in your own
system

Services in which the service provider is marked as a service provider managed in your own
system and for which the Send IDocs even if recipient is in the client field is selected in the
Define Communication Based on Service Types activity.

+


In this configuration, communication control would call the function modules Z_FUNC_1, Z_FUNC_2
and Z_FUNC_3.
Z_FUNC_4 would not be called: while the recipients service type is a service type managed in your
own system, the Send IDocs even if recipient is in the client field is not selected.
Z_FUNC_5 and Z_FUNC_6 would not be called, since BK00 and NETZ, the senders service types,
are not service types managed in your own system.





SAP AG Cookbook IDE Page 111 of 153

Cookbook
Intercompany Data Exchange


Inbound Processing
In inbound processing, the service types are derived definitively from the communication; in other
words, the recipient and sender of a message are clearly identifiable.

Note
One exception to this is sending and receiving schedules and load shapes. Sending and
receiving schedules and load shapes always takes place using the communication method
Communication according to service provider, even if the communication process specified is
Communication according to service type. The reason for this is that schedules and load
shapes also have to be sent to recipients who cannot be identified as service providers for a
point of delivery service.

6.2.6 Define Communication Based on Service Providers
This activity can be found in Customizing for Intercompany Data Exchange under Communication
Control -> Define Communication Based on Service Providers.

In this activity, you define communication control. You specify which events you want to use and
which function module is to be used in each case.
The input help proposes the function modules you entered previously under Define Function Modules
for Processing Events.

The settings made in this activity are only taken into account if you specify the communication
process according to service types in the Customizing activity Define Control Parameters.
This activity is blank in the standard delivery. You must enter the events you need for your business
processes.

Outbound Processing
In outbound processing, the system first reads all the services for a point of delivery and, in this way,
the corresponding service providers.
The sender is derived from the service provider who is managed in your own system. A service
provider managed in your own system is a service provider for whom the Service provider is
managed in own system field is selected in the Customizing activity Define Service Provider.


All service providers are possible recipients. This means a recipient can also be another service
provider who is managed in your own system. This means it is possible to send messages to the
same client.




SAP AG Cookbook IDE Page 112 of 153

Cookbook
Intercompany Data Exchange


Inbound Processing
In inbound processing, the service providers are derived definitively from the communication; that is
to say, the service provider to whom the message is addressed and the sender are clearly
identifiable.

Communication control is always read internally with the current days date. However, if future
changes to communication with a communication partner are already known, you can enter them
using the date field and transport them to the production system without these changes affecting
current communication.

You can influence communication control using the Condition type and Condition value fields. The
condition type determines which condition values can be used to specify communication control in
greater detail.
The following condition types are already defined in the standard system:
01 General condition type
SAP advises you not to use this condition type.
02 Profile type
Condition type used to send load shapes and schedules.
For example, if you choose condition type 02, all profile types are allowed as condition values.
You can define further condition types in Customizing for SAP Utilities under Tools -> System
Modifications -> User-Defined Enhancements for IDE -> Define Condition Types.

Note
One example to this is sending and receiving schedules and load shapes. This process always
takes place using the communication method Communication according to service provider,
even if the communication process specified is Communication according to service type. The
reason for this is that schedules and load shapes also have to be sent to recipients who cannot
be identified as service providers for a point of delivery service.

SAP AG Cookbook IDE Page 113 of 153

Cookbook
Intercompany Data Exchange



6.3 Process Management for Outbound Communication
6.3.1 Event Module
In the case of outbound messages, the event module is called directly by an application program.
You cannot change this function module without modifications.
Times at which event modules are called are predefined by SAP. In general, each call from the
application corresponds to an event, but the example below illustrates an exception to this.

The role of the event module is to determine the data environment required for communication
control. If this data (for example, the services and service providers involved) is known, the process
module is determined and called by communication control. In some cases, several process modules
may be determined, for example when communicating with several service providers simultaneously.

Process management takes place as follows:

Example: Contract Change

1. Call event module
When changing a contract, whether changing data, executing move-out or canceling move-out,
the system calls the event module ISU_COMEV_CONTRACT_CHANGED (Outbound Events:
Contract Master Data Change) in the database change module (ISU_DB_EVER_UPDATE or
ISU_DB_EVER_UPDATE_MOVE).
6
The relevant data (in this case, the old and new contract
data) is transferred in the interface.
Caution
Move-in is not a contract change. When move-in takes place, a new contract is created. An
event module is not called in this case.

2. Determine communication method
The event module first determines the communication method.
The actual business transaction is then determined in this event module. Besides a simple
change to data, the business transaction might also involve the ending of a contract or the
cancellation of such a transaction. These cases must be dealt with separately. The contract
end corresponds to event END_CONTR and cancellation of a contract end event
END_CON_R. The actual contract change triggers the event CH_CONTR, which is triggered
in addition to END_CONTR and END_CON_R.

3. Determine whether data exchange is to take place
The next step determines whether or not data exchange is to take place for this event. This
depends on the settings made in the Customizing activity Activate Processing Events.

6.
6
Most event modules have a technical name that begins with ISU_COMEV_*.

SAP AG Cookbook IDE Page 114 of 153

Cookbook
Intercompany Data Exchange



4. Call function module for communication control
If the event was activated in the Customizing activity Activate Processing Events, the system
calls the function module ISU_COM_CONTROL_ACCESS. This function module then calls the
function module ISU_COM_CONTROL_SERVTYPE (for communication according to the
service type) or ISU_COM_CONTROL_SERVPROV (for communication according to service
providers) depending on the communication method specified in the Define Control
Parameters.
ISU_COM_CONTROL_SERVTYPE
This function module reads the process modules to be called from the activity Define
Communication Based on Service Types (table ECOMCONTROL).
To do this, the function module determines the operational area and the service types
involved from the data transferred (primarily, the contract number in the example above).
ISU_COM_CONTROL_SERVPROV
This function module reads the process modules to be called from the activity Define
Communication Based on Service Providers (table ECOMCONTROLSP).
To do this, the function module determines the service providers and service types from
the data transferred. The function module also calls the BAdI for determining the
condition type and condition value.

5. Determine process modules
These modules determine the process modules. All process modules found are then called.

6.3.2 Process Module
The process module performs the necessary processing. In addition to the actual creation of the
IDoc, this can also involve further processing in the system, for example writing indexes or starting
workflows for continued monitoring of the process.

The event module calls this process module (see above step 5, Determine process modules).
Because this module is determined by means of the activities Define Communication Based on
Service Types (table ECOMCONTROL) or Define Communication Based on Service Providers (table
ECOMCONTROLSP), as previously explained, you can use a company-specific module.

In process management for outbound messages, the main task of the process module is to create
the IDoc (or, if applicable, several IDocs).

The event module transfers the data required for this purpose:
Data sent to the event module from the interface
Data determined by the event module

The process module obtains additional data that is required for the IDoc format in question.

The actual creation of the IDoc takes place when the function module
MASTER_IDOC_DISTRIBUTE is called.





SAP AG Cookbook IDE Page 115 of 153

Cookbook
Intercompany Data Exchange


6.4 Process Management for Inbound Communication
Receiving IDoc messages also involves two steps.

If you make the appropriate Customizing settings for the IDoc component in Customizing for the
Basis components under Application Link Enabling (ALE), the system determines a processing
function module for each inbound IDoc. This function module is referred to as the event module.
Communication control also determines and calls a process module as is done for outbound
messages. This module then performs the required activities in the IS-U System.

In contrast to outbound communication, inbound communication allows you to make changes to the
standard SAP modules on both levels without modifications. This is necessary because the inbound
IDoc must be analyzed in part in the event module in order to determine the required data for
determining the process module.
6.4.1 Event Module
In contrast to outbound communication, the system does not check whether or not data exchange is
to take place for the event when processing inbound messages. This means activating an event in
the Customizing activity Activate Processing Events is irrelevant in this case. The arrival of an IDoc
(and the allocation of an event module in the IDoc Customizing settings) is viewed as sufficient proof
that the event is actually to be processed.

To ensure that communication control is able to access the various Customizing activities, the
service providers must also be determined. These must be contained in the inbound IDoc. The
external ID of the service provider is usually specified here (ESERVPROV-EXTERNALID).

Process management takes place as follows:

1. Call event module
The system calls the function module ISU_COM_CONTROL_ACCESS_INBOUND.

2. Determine communication method
The event module first determines the communication method.
It next determines the actual business transaction. This usually depends on the message type
of the IDoc. However, it may also be the case that different business transactions are
processed using the same message type (for example, gaining a new customer, losing a
customer and changes to customer data). In this case, the system uses other data in the IDoc
(within the IDoc segments) to determine the business transaction. Each business transaction
corresponds to an event specified in the Customizing activity Define Processing Events.

3. Call function module for communication control
The system calls one of the following function modules, depending on the communication
method:
ISU_COM_CONTROL_SERVTYPE_INBND
ISU_COM_CONTROL_SERVPROV_INBND

4. Determine process modules
These modules determine and call the process module.

5. Write status record for IDoc

SAP AG Cookbook IDE Page 116 of 153

Cookbook
Intercompany Data Exchange


6.4.2 Process Module
The event module calls the process module. Because this module is determined by means of the
Customizing activities Define Communication Based on Service Types (table ECOMCONTROL) or
Define Communication Based on Service Providers (table ECOMCONTROLSP), as described
earlier, you can use a company-specific module here.
In contrast to outbound processing, the interface is always the same in inbound processing and the
whole IDoc is transferred.

The process module performs a further analysis of the IDoc data, which primarily involves
determining the relevant point of delivery.
Changes to data in the system are usually necessary as a result of the message received. To
prevent further IDocs being returned to the sender as a result of these changes (normal outbound
processing), the function module ISU_COM_EVENTS_DISABLE_IDE must be called before the
modules that change the data. This call prevents events from being triggered by normal
communication control. Once the changes have been made to the data, normal event processing
must be reactivated by calling the function module ISU_COM_EVENTS_ENABLE_IDE.

In many of the model process modules supplied by SAP for inbound processing, the data change is
stored in a separate function module, referred to as a script. Scripts access and change the data
using the standard SAP classes CL_ISU_*. These classes allow you to make changes without
having to worry about the consistency of the data. For information on how to use classes effectively,
see the coding of the standard scripts provided by SAP (function modules ISU_SCRIPT_*).

Note
You can also use master data templates to make more far-reaching changes (for example for
a customer change). These templates also contain the classes mentioned above.
For a detailed description on how to use master data templates, 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 Master Data Templates.

If the business process requires a reply, the reply IDoc is created directly in the process module.
Communication control is not required for this IDoc.



SAP AG Cookbook IDE Page 117 of 153

Cookbook
Intercompany Data Exchange


7 Integration of EDM Functions
7.1 Prerequisites
This unit provides a brief overview of sending and receiving load shapes and schedules. For more
information, see the documentation for Energy Data Management.

The settlement unit is a fundamental selection and sorting characteristic of EDM Settlement. To
create the settlement unit correctly, each point of delivery intended for settlement requires three
services for the service types distribution, supply and settlement coordination.
If, however, you only want to send load shapes from interval meters from the distributor to the
supplier, it is not absolutely necessary to define settlement units or a service for service type
settlement coordination.

Note
Load shapes and schedules are always sent using communication method Communication
Based on Service Provider even if you have set the communication procedure Based on
Service Type. This is because load shapes and schedules are also sent to recipients that
cannot be identified as the service provider of a point of delivery service.
7.2 Sending Load Shapes and Schedules from Settlement
In settlement, load shapes or schedules are determined in the settlement workbench using multiple
settlement steps. The settlement results are saved as so-called result profiles. If you want to send
these profiles, you have to implement another settlement step.
Settlement step SENDSUPR can send data to the service providers that are allocated to the
settlement unit. These are the distributor, the supplier and the settlement coordinator. You can use
this settlement step to control load shapes sent to the settlement coordinator, for example.
Settlement step SENDGRIDPR can send data to all distributors in the grid hierarchy. Generally, the
supplier uses this step to send the schedule to either all or to specific distributors in the grid
hierarchy.
Settlement step SENDGRSUPR combines the functions of the two previous steps to make a single
step.
In both steps, the existence of result profiles for the allocated register (business partner of the
service provider) determines, to which service providers you should send data. Therefore, the
appropriate profile headers must already be allocated to the relevant registers in the preliminary
stages.

Once the system has determined which service providers to send profiles to, transaction
Communication Control Based on Service Provider is called. Communication only occurs if all the
necessary entries have been made here.
Communication event SCH_PR_OUT is triggered. You use condition types and condition values in
communication control to decide what type of IDoc to send. If you choose condition type profile type
you can allocate various process modules subject to the condition values (the various profile types).
Templates currently exist for formats MSCONS (load shapes) and DELFOR (schedules) as
proposed by the VDEW (German Electricity Association).

SAP AG Cookbook IDE Page 118 of 153

Cookbook
Intercompany Data Exchange


7.3 Sending Any Profiles (Interval Meter)
To send any profiles you want, you can either use report REEDMSENDPROFILE01 or you can use
the Send Profiles transaction, which you can find in the menu for the Utilities Industry under Energy
Data Management Send Profiles. This function sends profiles that are not sent using the
settlement workbench. This mainly includes load shapes of interval meters that the supplier needs
for RTP billing.
Communication event INT_OUT_AC is triggered. If you need to send various formats depending on
profile type (interval dates, load shapes, schedules, for example), you must use the condition type as
described above.

You can restrict your selection using selection parameters. The selection screen looks like this:




You can use this function to check profiles in List Sent Profiles transaction, which you can also find in
the menu for the Utilities Industry under Energy Data Management Send Profiles.
7.4 Receiving Load Shapes and Schedules
On receipt of IDocs containing load shape or schedule data, the communication events INT_IN_ACT
or SCH_PR_IN are triggered, as is the case when IDocs are sent. The data is stored in the relevant
process modules as profile(s) for the relevant register.

SAP AG Cookbook IDE Page 119 of 153

Cookbook
Intercompany Data Exchange


8 Other Special Features
8.1 Changing From a Regulated to Deregulated Company
Companies that already run IS-U and would also like to take advantage of the IDE and/or EDM
components have to make the necessary changes to their master data in order to comply with the
deregulation data model. For some of these changes, you will have to use the corresponding
company-specific reports. You can use the migration tool to create new installations/contracts and to
add services.

The change from a regulated to a deregulated company is often made during a system upgrade. An
upgrade is, however, not absolutely necessary and the change can be made without. As well as the
changes to the data model and the implementation of the IDE function, it is also necessary to run a
test of all IS-U functions to ensure that the new combination of data does not cause any unwanted
side effects.

SAP recommends that you simultaneously change all affected installations/contracts for a division to
a deregulated status.
In theory, a distributor can choose to only use the deregulated model for customers who have
switched to another supplier. This would, however, increase the costs of each individual customer. It
would also be difficult for the processor to constantly switch between the regulated and the
deregulated models.

The individual steps you need to follow are dependent on many different factors: the number and
type of possible deregulation scenarios, for example, whether the system belongs to a distributor or a
supplier, whether the system is run in one or two clients, and so on.

Companies that still operate in a regulated environment but know that they will be operating in
deregulated environment in the foreseeable future, and that want to implement SAP Utilities, can
create the regulated contract in the system as a distributor contract. This means that:
The service type in the contract is Distribution
You must create your own company as service provider Distributor
You enter your own service provider in the relevant fields for the installation and the contract.
This alone allows most you to execute most deregulation activities (sending IDocs)
All communication events are inactive

The system recognizes this scenario as a regulated scenario.
When you switch to a deregulated environment, there are two ways to make the appropriate system
changes:

1. Manual (not recommended)
You can manually transfer register master data to a deregulated scenario.

Example

A customer switches to another supplier who acts as billing consolidator.
You must create the non-billable service supply in the system as an optional service.

SAP AG Cookbook IDE Page 120 of 153

Cookbook
Intercompany Data Exchange


You execute a contract change. The new supplier is included in the contract as service provider
invoicing and you can maintain the non-billable service supply.

2. Automatic
By using the general function module for change of scenario, the system automatically makes the
necessary adjustments to the master data. For more information see section 5.1.3.1. (Function
Modules for Change of Service and Scenario).
8.2 Company Without Their Own Billable Service
In deregulated markets it is possible that companies may want to run IS-U without IS-U-Billing. The
consequences are explained in the following examples:
8.2.1 Example 1: Meter Operator
A meter operator has decided to implement IS-U. The operator does not bill each individual customer
for device management and meter reading, but bills the distributor for a lump sum payment in
relation to the devices and sends the meter reading results or consumption values to the appropriate
distributors and suppliers.
For data model purposes, this company only needs the technical master data including connection
object and installation. Currently it is only possible to determine consumption values using IS-U-
Billing. It is therefore also necessary for this company to carry out billing with a single rate step in
order to copy the consumption data to the IDoc creation module. A complete data model including
contract, contract account and business partner is, however, necessary for billing. Billing also allows
you to use the existing IS-U Scheduling activity to send the consumption data at the right time.

SAP AG Cookbook IDE Page 121 of 153

Cookbook
Intercompany Data Exchange



8.2.2 Example 2: Rate Ready Scenario

Supplier as Billing Agent with Rate Ready (Distributors Perspective)
In this scenario, the distributor does not bill the customer. Theoretically, it would suffice to manage
points of delivery and their installations as well as the two non-billable services Supply and
Distribution in the system.

Point of
Delivery
55684
Contract
Account
Point of
Delivery
55684
Service
S-Type: SUPP
S-Provider: SUPP
Counting Class:
Installation
S-Type: GRID
Billing: SUPP
Contract
S-Provider: SUPP
Invoicing: SUPP
Counting Class:
Contract
S-Provider: GRID 01
Invoicing: SUPP
Counting Cl: CUST
Installation
S-Type: SUPP
Billing: SUPP
Installation
S-Art: GRID
Billing: SUPP
Di st r i but or
GRI D01
Suppl i er
SUPP
Service
S-Type: GRID
S-Provider: GRID
Counting Class:


In practice, however, the distributor wants to know who the customer is and therefore has to create a
contract account and a contract in order to have the connection between point of delivery and
business partner. Assuming that the distributor carries out meter readings and sends the
consumption data to the supplier, the same situation applies as in the previous example. Therefore
IS-U Billing is required.

Distributor as Billing Agent with Rate Ready (Suppliers Perspective)
Assuming that the distributor carries out meter reading and sends the consumption data to the
supplier, there is no need for the supplier to execute any billing activities.
In a mixed scenario, in which the supplier bills some customers and not others, the following options
exist to prevent billing when necessary:
Allocate items to contracts that will not be billed. These items are never prepared.
Select a rate category that creates void bills. These are ignored during invoicing and do not reach
bill printout.



SAP AG Cookbook IDE Page 122 of 153

Cookbook
Intercompany Data Exchange


9 Supplier and Distributor in One System
9.1 Recommendation: Separate Clients
For formerly regulated energy companies that now perform distribution and energy trading activities
as separate companies, the question arises of how to manage this structure in the system. The
following combinations are possible:
One client and separation in accounting using company codes
Separate clients
Separate systems

If the supplier and the distributor systems are run in one client, authorization problems arise. In many
deregulated markets, the law states that a supplier cannot use such an association with a distributor
to gain competitive advantage. Apart from a few exceptions, however, the instructions as to how this
law is to be implemented are often unclear. Therefore, SAP recommends that you run distributor and
supplier systems in separate clients. It is also possible that, in future, legislation will become stricter
and such a separation will be necessary.
9.2 Functional Special Features
No extended authorization concept is available for the event that you still want to manage the
supplier and the distributor in one system. In this case, the supplier is only permitted to see his own
customer data (and only for the period, for which the customers have been with the supplier). At
business master data level, this is controlled by the company code. However, as soon as you need to
work with register data or meter reading results, for example, there is no concept for managing
authorization for this data. The same applies for business partner contacts, data stored in the
installation facts (such as consumption values), and so on.

The decision to manage more than one service provider (supplier and distributor) in a single system
also affects communication control and therefore sending IDocs. During Communication Based on
Service Providers, data is sent to one of the service providers that is maintained in this Customizing
activity. If, therefore, you want to prevent IDocs from being sent within a system, do not maintain the
corresponding entries.
During Communication Based on Service Types, communication does not take place if the recipient
is managed in the same system. Because, however, it may still be necessary to send an IDoc (to
ensure consistency between your own and a third-party service provider, for example) there is a
checkbox in the Customizing activity Communication Based on Service Types that allows IDocs to be
sent.

SAP AG Cookbook IDE Page 123 of 153

Cookbook
Intercompany Data Exchange



9.3 Example Scenarios
Managing the distributor and the supplier in one system often results in a mixed scenario. This is
clarified in the following two examples. In both examples, we assume that the supplier is also acting
as sole provider.
9.3.1 Example 1: Strict Separation
This example concerns a utility company that operates in distribution and energy trading as one
company. Distributor and supplier are managed separately for each customer (different company
codes). For customers that have not switched supplier, the supplier associated with the distributor
continues to be used. As a consequence, the supplier acquires customers from third-party grids.
The following possibilities exist:
1. Customer has not switched.
Two contracts are managed in the system: a grid usage contract and a supply contract. The
service provider is entered in both contracts as service provider for billing and invoicing. In
this case it is also possible to enter ones own supplier as service provider for invoicing in the
grid usage contract as this supplier also creates the bill for third-party customers.
2. Customer has switched to another supplier (distributors perspective). A grid usage contract
and a non-billing service supply are managed in the distributors system.
3. Customer has switched to another supplier (suppliers perspective). A supply contract and a
non-billable service distribution are managed in the suppliers system.
9.3.2 Example 2: Separation Only When Necessary
This example concerns a utility company that operates in distribution and energy trading as one
company. You do not need to separate distributor and supplier for customers that have not switched
supplier. This means the company acts as both distributor and supplier. A supplier that acquires
customers from both his own and from third-party grids also exists.
The following possibilities exist:
1. Customer has not switched.
A contract is managed in the utility companys system. As described in previous units, this
should be a deregulated contract. This means that the deregulation fields in the contract and
the installation must be maintained and must contain the distributor. As no other services are
available, the system recognizes this as a regulated scenario.
In addition, SAP recommends that you manage the non-billable service Supply using a
separate supplier. This corresponds better with the following situations and it is easier for the
processor to identify the supplier.
2. Customer has changed to a third-party supplier.
A grid usage contract and a non-billable service Supply is managed in the utility companys
system.
3. Customer from own grid switches to own supplier.
A grid usage contract and a supply contract are managed in the utility companys system.
Your own supplier is entered in the grid usage contract as service provider for invoicing.
Customers are acquired from third-party grids.
A supply contract and a non-billable service Distribution are managed in the utility companys system.



SAP AG Cookbook IDE Page 124 of 153

Cookbook
Intercompany Data Exchange


10 Functional Enhancements
Enhancement and modification of existing IDE processes requires a good understanding of
communication control.

Note
For further information on communication control, see unit 6.
10.1 Changes to Existing Processes
10.1.1 Changing Processing of Outbound Messages

Example
You want to change the way in which outbound messages are created, for example, because
you want to enter different data in the IDoc or because you want to create an IDoc of a
different type.
In addition to IDoc creation, you also want to execute other functions.

You can do all this by means of a user-defined process module. This module must use the same
interface as the standard module supplied by SAP for this event (see the Customizing activity Define
Function Modules for Processing Events).
Note
You can copy the standard module provided by SAP and modify it according to your
companys requirements.

You should then set up communication control so that your module is called when the event in
question takes place.

If you want to create an IDoc of a different (new) type, you must define the IDoc type and the
segment types that belong to it beforehand. You can access these functions in the menu under Tools
-> Business Communication -> IDoc Basis -> Development -> IDoc Segments or under Tools ->
Business Communication -> IDoc Basis -> Development -> IDoc Types.
10.1.2 Changing Processing of Inbound Messages
If you want to change how inbound messages are processed, you can make changes without the
use of modifications in the following two places:
You can change the IDoc Customizing settings to call a different (customer-specific) event
function module.
You can change the communication control settings to call a different (customer-specific)
process module.
Note
We recommend that you adopt this second option. In this case, you do not have to determine
the sender, recipient and point of delivery, since this is done in the event module.


SAP AG Cookbook IDE Page 125 of 153

Cookbook
Intercompany Data Exchange


Note
To create your own process module, you can copy the standard module delivered by SAP and
modify it according to your companys requirements.

Note
If you make changes to SAP objects (for example, changing the rate category, customer
address etc.), you should work with the classes provided by SAP (CL_ISU_PARTNER;
CL_ISU_CONTRACT etc.). This means it is easy for you to make consistent changes to data
using ABAP-OO (object-oriented ABAP enhancement). The standard process modules
supplied by SAP contain examples of this.
10.2 Adding a New Process
10.2.1 New Processes for Outbound Messages
If you also want to create outbound messages, you must first define the business processes for
which the messages are to be created in the SAP System. You must then analyze the coding to
determine the best point at which a new event can be triggered. You may also be able to use an
existing event, in which case you should proceed as described in the previous section.
If a program enhancement has already been provided by SAP at the point at which you want to
trigger the new event (SAP enhancement via SMOD/CMOD, BAdI or a workflow start), you should
use this to call your own event function module. If SAP does not provide an enhancement, you must
make a program modification. To keep this modification as minor as possible, you should only call
one function module (the event function module).
You can use the standard SAP event modules as a guideline when creating a new event module. To
be able to use the communication control, you must create a new event in the Customizing activity
Define Processing Events. You must then make entries in the following activities for this event:
Activate Processing Events
Define Function Modules for Processing Events
Define Communication Based on Service Types or Define Communication Based on Service
Providers
You can use one of the standard process modules provided by SAP as a template for the process
module used to create the IDoc.
10.2.2 New Processes for Inbound Messages
You can integrate new processes for inbound messages (for example, for message types not
supplied in the standard system) as follows.
You must enter a processing module (event module) for the inbound message in IDoc Customizing.
You can create this function module based on the standard event modules provided by SAP. If
communication control is to be used in this module (this does not have to be the case), you must
create a new event in the Customizing activity Define Processing Events. You must then also make
entries in the following activities for this event:
Activate Processing Events
Define Function Modules for Processing Events
Define Communication Based on Service Types or Define Communication Based on Service
Providers

The procedure for creating new process modules was explained in the previous section (Changing
Processing of Inbound Messages).

SAP AG Cookbook IDE Page 126 of 153

Cookbook
Intercompany Data Exchange


10.3 Standard Enhancements
SAP has already planned enhancements to central parts of IDE.

BAdIs that can be used to influence the process modules determined have been implemented for
both types of communication control. For further information, see unit 6 (Communication Control).

Two of the SAP enhancements deal with the creation and analysis of alternate point of delivery keys.
The external point of delivery ID is used by the IDE functions to identify a point of delivery and the
relevant data objects (installations, contracts, business partners etc.). However, if a market does not
have a definitive point of delivery ID or the ID is not to be used for some reason, you can also work
with a different key. This results in problems in identifying the point of delivery from this key when
inbound messages are received and in entering the correct key for outbound messages.
You can store coding that creates a separate key for communication in the function exit
EXIT_SAPLECDEREG01_001.
Function exit EXIT_SAPLECDEREG01_002 allows you to determine the data environment (in
particular, the point of delivery) from the point of delivery key in an inbound message.

You can determine the type of payment plan to be created in a further function exit
(EXIT_SAPLECDEREG01_003). This exit is called in the method GET_TYPE_OF_PAYMENTPLAN
of class CL_ISU_CONTRACT_ACCOUNT.

If a supplier decides to stop supplying a customer, the distributor can determine a new supplier in a
number of different ways. You can store coding defining this procedure in the function exit
EXIT_SAPLECDEREG01_004. This exit is called in the function module
ISU_GET_SUPPLIER_AFTER_DROP.

The function exit EXIT_SAPLEUSAGE_001 is used to determine the cosine phi in communication
from consumers. It is called in the event function module ISU_PREPARE_USAGE_INFO.



SAP AG Cookbook IDE Page 127 of 153

Cookbook
Intercompany Data Exchange


11 General
11.1 Performance
The effect of intercompany data exchange on system performance has not been analyzed, and
indeed it would be almost impossible to make a clear statement due to the large number of possible
scenarios involved.
The mass processes billing, invoicing and posting play a critical role in performance.
The IDoc containing consumption information is created directly in billing. This means the
complexity of IDoc creation directly affects performance in billing.
Invoicing is affected to a lesser degree because here only the trigger is written for report
REDISND1. The additional load on performance here comes indirectly during the posting
procedure see below.
Bills sent electronically do not have to be printed out, so that performance can be expected to
improve in this area.
Each posting procedure involves the time required by the system to determine whether entries
are required in table DFKKTHP (Transfer Records for Billing on Behalf of Third Party) or
DFKKTHI (Transfer Records for Invoice Issue by Third Party).
11.2 Data Volume and Archiving
The data volume is linked directly to the number of billing documents. This affects the tables
ECROSSREFNO (IDE: Reference Number for IDoc), EREFDISSUP (Reference Between
Documents of Suppliers and Distributors), DFKKTHI (Transfer Records for Invoice Issue by Third
Party), DFKKTHP (Transfer Records for Billing on Behalf of Third Party) and EPAYTHP (IDE:
Transfer Records for Third Party Payments). Of course, the tables actually used depend on the
scenario. Archiving is not possible for these tables at present and is also not necessary. If you want
to delete old entries, you must do this using company-specific reports.

The area most seriously affected by data volumes is IDoc administration. This area contains
standard archiving tools. To access these tools, choose Tools -> Administration -> Administration ->
Archiving in the SAP menu. The name of the archiving object is IDoc.
11.3 Migration
This section describes the transfer concept for points of delivery and NB services and goes on to
describe the individual migration objects in greater detail.
11.3.1 Transfer Concept for Points of Delivery and Point of Delivery Services
Points of delivery and NB services can be transferred during IS-U migration using various process
flows, depending on your requirements.

SAP AG Cookbook IDE Page 128 of 153

Cookbook
Intercompany Data Exchange



11.3.1.1 Process Flow for Deregulated Installations

1. Create installation using migration object INSTLN:
When you create the installation, the system creates a (deregulation) point of delivery in background
processing. You can then control how the point of delivery is created by transferring structure POD.
If you specify a structure type and point of delivery ID in structure POD, the system creates a point of
delivery of this structure type and with this ID and marks it as a deregulation point of delivery.
If you do not specify a structure type and point of delivery ID, the point of delivery is only created with
an internal key.

2. Change/enhance existing points of delivery using migration object PODCHANGE:
To allocate a grid to the existing point of delivery (which might, for example, have been created along
with the installation) or to change other data on the point of delivery (for example, assigning it to a
device as a technical point of delivery), you must use the object PODCHANGE.

3. Create NB services using migration object PODSERVICE:
You use field EXT_UI in structure ESERVICED to transfer the point of delivery ID for which the
services are to be created.

4. Create further points of delivery using migration object POD:
To create further points of delivery (for example, technical points of delivery for EDM), you must use
the migration object POD. During this process, you can use the structures TECH_ANLAGE,
TECH_LNR and TECH_LZW to allocate installations, devices or registers to the point of delivery.

11.3.1.2 Process Flow for Non-Deregulated Installations

1. Create installation with migration object INSTLN:
When you create an installation, the system creates a (deregulation) point of delivery in background
processing with no point of delivery ID but instead an internal key.
You do not need to transfer structure POD for object INSTLN. No further activities are required.

11.3.2 Installation
11.3.2.1 Migration Object INSTLN
The migration object INSTLN includes all the data required to create the IS-U master data object
installation.
When you create an installation, the system creates a point of delivery in background processing.
If structure POD is not used or a point of delivery ID is not transferred in structure POD, the system
still creates a point of delivery with an internal key in the role deregulation point of delivery.
If you use structure POD and a structure type and point of delivery ID are transferred in the structure,
the point of delivery is created with the specified point of delivery ID. When the point of delivery ID is
entered, you must also specify a grid.
If an existing point of delivery ID is transferred, the system attempts to allocate the installation to this
point of delivery. This means it is possible to allocate the same point of delivery to several
installations. This can only be done if all the installations belong to the same premise and have
service types of different categories.

SAP AG Cookbook IDE Page 129 of 153

Cookbook
Intercompany Data Exchange


You can create installation facts along with the installation. To do this, you must flag the relevant
structures for generation. For a description of the individual structures and their use, see the
migration object FACTS.
Dependencies
You cannot execute migration of installation data until migration has taken place successfully for the
premises (migration object PREMISE).
Commit buffering
You can activate commit buffering for the migration object INSTLN.
Database tables
Data is written to the following database tables during the import:
EANL Installation
EANLH Installation Time Slice
EUIHEAD PoD Header Data
EUITRANS Transformation of Internal/External Point of Delivery Number
if a point of delivery ID was transferred
EUIGRID Allocation of PoD to Grid
EUIINSTLN Allocation of Installation to PoD
ETTIFN Installation Facts (Normal), if installation facts were transferred
Number ranges
The following number range objects are read:
ISU_EANL Number Range: Installation (Billing Object)
ISU_EDM_SC Number Range for Source System

11.3.2.2 Migration Object INSTLNCHA
The migration object INSTLNCHA is used to change the IS-U master data object installation.
This object can be used to make changes (for example changed rate data) to attributes within the
historical period transferred for installations created during migration.
Use the migration object FACTS for changes to installation facts and PODCHANGE for changes to
the point of delivery.
Dependencies
Changes to the installation can only be transferred once migration has been completed successfully
for the installations (migration object INSTLN).
See also the documentation on the transfer concept for rate data in the migration workbench.
Commit buffering
You can activate commit buffering for the migration object INSTLNCHA.
Database tables
Data is written to the following database tables during the import:
EANL Installation
EANLH Installation Time Slice

SAP AG Cookbook IDE Page 130 of 153

Cookbook
Intercompany Data Exchange



11.3.3 Point of Delivery
11.3.3.1 Migration Object POD
The migration object POD includes all the data required to create the point of delivery.master data
object.
When you create a point of delivery, you can also allocate it to one or more installations for a
specified period of time. You can make this allocation separately by deregulation point of delivery
(point of delivery allocated to installations) and by technical point of delivery (point of delivery
allocated to installations, devices or registers).

Note
When you create an installation, the system creates a point of delivery automatically in
background processing. The point of delivery ID can also be allocated at this time.

One of the codes supported must be specified in the ACTION field in the automation data
component being used for the point of delivery:

Automation data
component
Action in
field ACTION
Comment
EXTUI M Creates a time slice for the point of delivery ID.

SOURCE M Creates a time slice for the source system.

GRID M Creates a time slice for the grid.
If the point of delivery ID is specified, a grid must also
be specified for the period in question.

I Creates a time slice for allocating an installation in the
role Deregulation
DEREG_ANLAGE
D Removes the allocation.

I Creates a time slice for allocating an installation in the
role Technical.
TECH_ANLAGE
D Removes the allocation.

I Creates a time slice for allocating a logical register. TECH_LZW
D Removes the allocation.


Dependencies
Migration of point of delivery data cannot take place until migration has been performed successfully
for the installations (migration object INSTLN) or devices (migration object DEVICE).
Commit buffering
You can activate commit buffering for the migration object POD.





SAP AG Cookbook IDE Page 131 of 153

Cookbook
Intercompany Data Exchange


Database tables
Data is written to the following database tables during import:
EUIHEAD PoD Header Data
EUITRANS Transformation of Internal/External Point of Delivery Number
EUIGRID Allocation of PoD to Grid
EUIINSTLN Allocation of Installation to PoD
EUILZW Allocation of Logical Register to PoD
Number ranges
The following number range object is read during import:
ISU_EDM_SC Number Range for Source System

11.3.3.2 Migration Object PODCHANGE
The migration object PODCHANGE includes all the data required to change the object point of
delivery. When you create the object, you can also allocate it to one or more installations for a
specific period of time. For a description of the automation data components, see the documentation
on migration object POD (11.3.3.1).
Dependencies
Migration of data for changing points of delivery cannot take place until migration of the installations
(migration object INSTLN) or points of delivery (migration object POD) has been performed
successfully.
Commit buffering
You can activate commit buffering for the migration object PODCHANGE.
Database tables
Data is written to the following database tables during import:
EUIHEAD PoD Header Data
EUITRANS Transformation of Internal/External Point of Delivery Number
EUIGRID Allocation of PoD to Grid
EUIINSTLN Allocation of Installation to PoD
EUILZW Allocation of Logical Register to PoD
Number ranges
The following number range object is read:
ISU_EDM_SC Number Range for Source System

11.3.4 NB Services
11.3.4.1 Migration Object PODSERVICE
The migration object PODSERVICE includes all the data required to create one or more point of
delivery service objects. The services are created according to the default values specified during
Customizing. The service automation data is combined with the default values. For this purpose,
entries must be made in at least the following fields of automation data parameters:

ESERVICED-INT_UI, is used to identify the point of delivery by its internal key
ESERVICED-EXT_UI, serves as an alternative to identifying the point of delivery by its ID
(key date is the start date)
ESERVICED-SERVICE_START, start date for services
ESERVICED-SPARTE is optional and is used to delimit the proposals to services in the
specified division

ESERVICED-SERVICE is used to identify the services to be influenced.

SAP AG Cookbook IDE Page 132 of 153

Cookbook
Intercompany Data Exchange



The following fields must contain entries for use in the proposal procedure based on service provider
relationships. The fields are used as selection criteria for the proposals.
SELECTIONS-VKONTKL the contract account class is used together with parameter
POLR to determine the enrollment type
SELECTIONS-SERVPROV_OWN service provider managed in own system
SELECTIONS-GRID_ID if specified, this is the grid used. Otherwise, the system uses the
grid from the point of delivery.
SELECTIONS-POLR see SELECTIONS-VKONTKL

The following field must contain an entry for use in the proposal procedure based on the operational
area:

SELECTIONS-OPAREA if specified, this is the operational area used. Otherwise, the
system determines the operational area as described in section 5.1.1.2.

The system only takes account of those service types in the automation data for which services are
proposed. Other service types in the automation data are ignored. This means the mechanism of
automation data is not suitable for creating services of your choice independently of the service types
proposed from the Customizing settings.
Dependencies
Migration of point of delivery data cannot take place until migration has been performed successfully
for the points of delivery (migration object POD) or installations (migration object INSTLN).
Commit buffering
You can activate commit buffering for the migration object PODSERVICE.
Database tables
Data is written to the following database table during import:
ESERVICE NB Services
Number ranges
The object keys of the point of delivery services are determined by means of the following number
range:
ISU_EVER Number Range: IS-U Contract


SAP AG Cookbook IDE Page 133 of 153

Cookbook
Intercompany Data Exchange



11.4 Problem of Duplicate Device Numbers

Example
A supplier gains new customers in grids run by different distributors. The distributors pass on
the device data to the supplier, who creates device information records in his system using the
device number as the key. To keep device management as simple as possible, the supplier
creates as few material masters as possible. This may result in the same device number being
allocated to several device information records. Since a serial number can only be assigned
once for each material, the supplier will have difficulty creating this device in the system.

There are two possible solutions to this problem:

1. If the serial number has already been allocated, the system is to create a new material
automatically.
2. If the serial number has already been allocated, the system is to append a sequence number to
the device number; for example, if 8844773 already exists, the new device information record is
created with the number 8844773-02.
The suffix can then be suppressed in customer contacts and in bill printout to avoid queries from
the customer.

In both these cases, the required functions can be stored in the process modules that process the
inbound IDoc containing the device information. This means a modification is not necessary.
11.5 Statistics
At present, no statistical evaluation is available for messages sent or received over and above the
functions provided with the standard IDoc tool.
Information from IDE objects such as the grid, distributor, point of delivery or service provider is not
provided for BW at present.



SAP AG Cookbook IDE Page 134 of 153

Cookbook
Intercompany Data Exchange


12 Appendix
12.1 Business Add-Ins
Business Add-Ins allow you to make customer-specific functional enhancements by implementing
the interfaces provided and by overwriting the standard methods provided by SAP.

1. ISU_IDE_ENROLL
Used by the proposal procedure based on the service provider relationship.
Method Purpose Used by function
ENROLL_TYPE_DETERMINE Determine enrollment type as key in
service proposal procedure based on
service provider relationships.
ISU_IDE_ENROLL_DEFAU
LT
ISU_IDE_NBSERV_DEFAU
LT

2. ISU_IDE_SCENARIO
Scenario determination using function ISU_IDE_SCENARIO.
Method Purpose Used by function
SCENARIO_DEFINE Identification of customer-specific scenarios ISU_IDE_SCENARIO_SERVICES


3. ISU_IDE_COM_CONTROL
Used in communication control.
Method Purpose Used by function
OPAREA_DETERMINE Determine operational
area in service
proposal procedure
based on service area
ISU_IDE_DETERMINE_OPAREA
ISU_COM_CONTROL_ACCESS_ENROLL
ISU_COM_CONTROL_SERVTYPE
ISU_COM_CONTROL_SERVTYPE_INBND
LEIDE_EDIEL_OUTF04
COND_DETERMINE_OUTBOUND Influence the
condition type and
condition value when
sending invoice data
using communication
control based on
service providers
ISU_COM_CONTROL_SERVPROV
COND_DETERMINE_INBOUND Influence the
condition type and
condition value when
receiving invoice data
using communication
control based on
service providers.
ISU_COMEV_IDOC_ISU_INT_USAGE
ISU_COMEV_IDOC_ISU_SCH_PROFILE



SAP AG Cookbook IDE Page 135 of 153

Cookbook
Intercompany Data Exchange



4. ISU_SCENARIO_SWITCH
Used when changing supplier from the distributors perspective by the function that makes the
master data changes.

Method Purpose Used by function
NEW_CONTRACT_CHANGE Modify data on a new
contract
ISU_SERVICE_SWITCH_EXECUTE
NEW_INST_OBJ_CHANGE Modify data on a new/
reused installation
ISU_SERVICE_SWITCH_EXECUTE
12.2 SAP Enhancements
The following enhancements have been available since Release 4.62 and earlier.

1. ECDEREG
Function group: XECDEREG01

Function module Purpose Used by function
EXIT_SAPLECDEREG01_001 Create your own
reference number for
business partner,
premise and installation
that can be used in
communication instead
of the point of delivery ID
ISU_BUILD_OWN_SUPPLY_ID
ISU_GET_OWN_SUPPLY_ID
ISU_GET_OWN_SUPPLY_ID_BY_CO
NTR
EXIT_SAPLECDEREG01_002 Determine the
installations from your
internal reference
number
ISU_ANALYSE_OWN_SUPPLY_ID
EXIT_SAPLECDEREG01_003 Determine the default
value for the payment
plan category when
creating a contract
account
ISU_GET_PYPLT_DEFAULT
EXIT_SAPLECDEREG01_004 Determine provider of
last resort when a
contract is ended
ISU_GET_SUPPLIER_AFTER_DROP

2. EUSAGE
Function group: XEUSAGE

Function module Purpose Used by function
EXIT_SAPLEUSAGE_001
Allocate cosine-phi for an
IDoc for monthly
consumption.
ISU_PREPARE_USAGE_INFO_REV
ISU_PREPARE_USAGE_INFO
ISU_PREPARE_USAGE_INFO_REV_OLD!
ISU_PREPARE_USAGE_INFO_OLD!


SAP AG Cookbook IDE Page 136 of 153

Cookbook
Intercompany Data Exchange



12.3 Important Function Modules
12.3.1 ISU_SCENARIO_DETERMINE
Function module recommended for analyzing the scenario in relation to only one contract. The
function module provides information such as who invoices and bills the contract, and whether or not
an electronic invoice is to be sent. You can also request detailed information on the service providers
(billing, invoicing, owner) by calling the function module ISU_SERVICEPROVIDE_READ. To improve
performance, this function module is only called when detailed information is actually requested for
the service provider.
12.3.2 ISU_IDE_SCENARIO
Determines all scenarios for all related services. The scenarios that can be determined automatically
are described below under Scenarios.
12.3.3 ISU_ANALYSE_CONTRACT_FOR_EDI
Determines the payment method for a contract.
12.3.4 ISU_SERVICE_PROVIDER_READ
In addition to the service provider, this function module provides further information, such as the
service type, service type text and service category. This is all available in the data structure
SPROVIDER.
12.3.5 ISU_COM_EVENTS_DISABLE_IDE
Disables sending IDocs via communication control. This is necessary, for example, in processes that
are triggered by inbound IDocs and that cause changes to data. Updates of IS-U master data
normally result in communication control being called. However, if an update is performed based on
an IDoc containing information on a change, it is of course necessary to prevent a further IDoc from
being sent.
The function module is normally positioned before script execution.
12.3.6 ISU_COM_EVENTS_ENABLE_IDE
Enables sending IDocs. The function module is normally positioned before script execution.
12.4 Processes and Events
This section describes the various processes in IS-U that trigger events for outbound communication.
The events are implemented in the standard system and it is not always clear to see which event can
be triggered when and where. This is easier to determine in inbound communication because the
function module implemented in the IDoc is the event module and can therefore be replaced by
customer functionality if you use your own IDocs.
In contrast, the accompanying event modules for outbound communication are not templates and
can only be changed by means of modifications. They are listed here to facilitate debugging. The
Calling position column lists the position in the program that calls the event module. Where this
description is kept general, the exact name of the program is not required. The calling positions can
usually be identified easily from the where-used list.

..... Page 137 of 153
.... Cookbook

Process Calling position Event module Event
Create billing document
Only consumption information is sent.
In the update part in billing isu_prepare_usage_info billcreate
Create invoice document
Only the trigger (table EITEDI) is
written in billing.
Report
redisnd1
isu_comev_process_invoice inv_create
Cancel billing
The cancelled consumption is sent.
Function module
isu_bill_cancellation
isu_prepare_usage_info_rev billrevers
Cancel invoicing
Only the trigger (table EITEDI) is
written in invoicing cancellation.
Report
redisnd1
isu_comev_process_invoice inv_create
Simulate billing
Caution
This event should only be active for
testing but never in a production
system.
In the update part in billing isu_prepare_usage_info s_billcrea
Simulate invoicing
Caution
This event should only be active for
testing but never in a production
system.
Report
redisnd1
isu_comev_process_invoice s_inv_crea
Enter meter reading
At present, IDocs cannot be sent
directly when meter readings are
entered or changed.
Not applicable Not applicable ----
Replacement In the update part of the application isu_comev_billinginst_changed exch_devic
Device modification In the update part of the application isu_comev_billinginst_changed exch_devic
Change installation facts
Also applies to reference values
In the update part of the application isu_comev_instfacts_changed ch_facts
Change installation In the update part of the application isu_comev_instln_changed ch_instln
Change NB service In the update part of the application isu_comev_nbservice_changed ch_nbserv
Change contract In the update part of the application isu_comev_contract_changed ch_contr
Change connection object In the update part of the application isu_comev_coaddr_changed ch_coaddr
Change contract account In the update part of the application isu_comev_account_changed ch_account

SAP AG ..... Page 138 of 153


Cookbook
Intercompany Data Exchange


Process Calling position Event module Event
Change business partner In the update part of the application isu_comev_partner_changed ch_partner
Change load profile
This refers to a change in the
allocation of the load profile to an
installation
In the update part of the application isu_comev_lpass_changed ch_lpassgn
Move-out / end contract In the update part of the application isu_comev_contract_changed
Same module is used to change
contracts. The system identifies which
event is to be triggered from the
changed fields.
end_contr
Cancel move-out / end of contract In the update part of the application isu_comev_contract_changed
Same module is used to change
contracts. The system identifies which
event is to be triggered from the
changed fields.
end_con_r
Clear receivables
In some markets, it may be necessary
to inform the recipient of a payment in
a Billing Agent Customer Payment
scenario in advance that the customer
has paid (before the payment
information is sent).
In each type of posting in FI-CA
(events 0010 and 0020)
isu_prep_fica_data_for_comm
More than an event module: also
determines whether DFKKTHI and/or
DFKKTHP is written.
clearitem
Cancel FI-CA document
Only intended for checking.
Caution
Do not use becomes obsolete in a
later Release.
Not implemented isu_deregulation_checks_0060
Caution
Do not use
canc_fica

SAP AG ..... Page 139 of 153


Cookbook
Intercompany Data Exchange


Process Calling position Event module Event
Write off receivables
In some markets, it may be necessary
to inform the recipient of a payment
that the receivable has been written off
for a customer in a Billing Agent
Customer Payment scenario.
In each type of posting in FI-CA
(events 0010 and 0020)
isu_prep_fica_data_for_comm
More than an event module: also
determines whether DFKKTHI and/or
DFKKTHP is written.
writeoff
Send billing agent payment
information
Report
reremitadv
There is no actual event module. The
report calls communication control with
the event directly.
paym_postd
Simulate Billing Agent payment
information
Report
reremitadv
There is no actual event module. The
report calls communication control with
the event directly.
pay_propos
Send Sole Provider payment
information
Report
reremitadv_soleprv
There is no actual event module. The
report calls communication control with
the event directly.
remitadvs
Simulate Sole Provider payment
information
Report
reremitadv_soleprv
There is no actual event module. The
report calls communication control with
the event directly.
sremitadvs
Send profiles
You can send any profiles you wish,
for example measured values from
interval meters.
Report
reedmsendprofile01
isu_comev_int_profile_out int_out_ac
Send invoicing results
Independent of whether load shapes
or schedules are being sent. The
condition type in communication
control makes this distinction.
From invoicing step using the method
send_profiles.
isu_comev_sch_profile_out sch_pr_out
Create service orders
From the perspective of the service
provider who receives the order from
the customer and passes it on to the
service provider executing the order.
Report
reservicerequest_dereg
isu_comev_servicerequest_creat snd_srvreq

SAP AG ..... Page 140 of 153


Cookbook
Intercompany Data Exchange


Process Calling position Event module Event
Enrollment
From the perspective of the supplier
who obtains a new customer. Normally
part of an enrollment workflow.
BOR method
IsuIdeTran.SendReqEnroll
The method is based on SD
enrollment from Release 4.62.
isu_map_data_enroll_req snd_enroll
Initiate end of contract
From the perspective of the distributor
who receives information that the utility
contract is to be ended from the
customer and must now inform the
supplier.
BOR method
IsuDeregSupport.
RequestDropInternal
The method should, for example, be
called from a Front Office process.
isu_comev_req_drop_internal int_drop
Request customer data
From the perspective of the supplier
who obtains a new customer. Unlike
the event snd_enroll, further
information is queried here in
preparation. This is specifically
designed for the Scandinavian market.
Not implemented in a sample method
at present. The event module must be
called from a separate program (for
example, a workflow step).
isu_comev_ediel_prodat_z01_out req_enrinf


SAP AG ..... Page 141 of 153

.... Cookbook
Intercompany Data Exchange


12.5 IDocs
12.5.1 Outbound View
This section lists the process modules that create each IDoc, meaning that the information here is
not only relevant for an outbound view. IDocs from inbound processes can sometimes be created
without the use of communication control (direct reply to the sender), but this type of creation is not
dealt with here. The next section describes which inbound process module creates which IDoc.
As a cross-reference, the last column indicates the event that leads to creation of the IDoc.
From Release 4.62 onwards, IDocs are subject to a naming convention whereby the name of the
IDoc indicates the standard and format for which it is intended (for example, ISU_VDEW_MSCONS).
All the IDoc IDs listed that do not conform to this convention, in other words, that have a more
mnemonic name, generally correspond to a North American ANSI X.12 format. The corresponding
EDI format is also indicated in these cases.

SAP AG .....
..... Page 142 of 153

.... Cookbook


IDoc type Message type Process module(s) Event(s)
isu_vdew_mscons isu_discrete_usage_information isu_compr_vdew_mscons_usg_out billcreate
isu_vdew_mscons isu_interval_usage_information isu_compr_vdew_mscons_int_out
isu_compr_vdew_mscons_prof_out
int_out_ac, sch_pr_out
isu_vdew_delfor isu_sch_profile_information isu_compr_vdew_delfor_out sch_pr_out
isu_ediel_mscons mscons isu_compr_ediel_out_mscons_usg billcreate
isu_usage_data
Corresponds to EDI 867
isu_monthly_usage_information isu_IDoc_usage_mon_create billcreate, billrevers
isu_usage_data
Corresponds to EDI 867
isu_monthly_usage_simulation isu_IDoc_usage_mon_create s_billcrea
ediel_prodat prodat isu_compr_ediel_out_prodat_chn
isu_compr_ediel_out_prodat_z05
isu_compr_ediel_out_prodat_z03
isu_compr_ediel_out_prodat_z01
ch_account, ch_coaddr,
ch_contract, ch_partner,
ch_instln, ch_lpassgn,
ch_facts, end_contr,
exch_devic, snd_enroll,
req_enrinf
isu_general_reqest_response
Corresponds to EDI 814
isu_change_request isu_compr_req_change ch_account, ch_coaddr,
ch_contract, ch_partner,
ch_instln, ch_lpassgn,
exch_devic,
ch_premise,
ch_nbservice, ch_facts
isu_general_reqest_response
Corresponds to EDI 814
isu_drop_request isu_compr_end_contr
isu_compr_int_drop
end_contr, int_drop
isu_general_reqest_response
Corresponds to EDI 814
isu_enrollment_request isu_send_req_enroll_IDoc snd_enroll
isu_contract_payment
Corresponds to EDI 568
isu_contract_payment isu_IDoc_cleared_item_create clearitem
isu_request_response
Corresponds to EDI 814
isu_reinstate_request isu_compr_end_con_r
isu_compr_int_drop
end_con_r, int_drop
isu_invoice_4010
Corresponds to EDI 810,
version 4010
isu_bill_information_4010 isu_IDoc_invoice_create inv_create

SAP AG .....
..... Page 143 of 153

Cookbook
Intercompany Data Exchange


IDoc type Message type Process module(s) Event(s)
isu_invoice_4010
Corresponds to EDI 810,
version 4010
isu_bill_simulation isu_IDoc_invoice_create s_inv_crea
isu_remittance_detail
isu_remit_adv_header
isu_remittance_adv_control
3 IDocs are created and these
are combined to form EDI 820.
isu_rem_adv_detail
isu_remittance_advice_hdr
isu_rem_adv_control
isu_IDoc_remittance_detail
isu_create_remit_adv_epaythp
paym_postd,
pay_propos, remitadvs,
sremitadvs
isu_maintenance_service_orde
r
Corresponds to EDI 650
isu_maint_so isu_send_servreq_IDoc snd_srvreq
isu_writeoff
Corresponds to EDI 248
isu_writeoff isu_IDoc_writeoff_create writeoff


SAP AG ..... Page 144 of 153

.... Cookbook

12.5.2 Inbound View
In the case of inbound IDocs, a function module is called according to various parameters defined in
the partner profile. From the point of view of deregulation, these function modules are event modules
that identify which event is to be triggered from the IDoc information. The following table lists the
event modules according to the IDoc type and message type. This list basically corresponds to the
standard settings in the assignment table for IDocs and message types, which you can access in the
SAP menu under Tools ALE ALE Development IDocs Inbound Processing Function
Module Assign IDoc and Message Type. The table below also indicates the communication event
triggered by the event module.

In some cases, you need to use a message code to further distinguish the objects in the partner
profile.

SAP AG .....
..... Page 145 of 153

.... Cookbook


IDoc type Message type/code Event module Event(s)
isu_vdew_mscons isu_interval_usage isu_comev_IDoc_isu_int_usage int_in_act
isu_vdew_mscons isu_interval_usage_information isu_comev_IDoc_inbound_int_usg int_in_act
isu_vdew_delfor isu_sch_profile_information isu_comev_IDoc_inbound_sch_pro sch_pr_in
isu_vdew_delfor isu_sch_profile isu_comev_IDoc_isu_sch_profile sch_pr_in
isu_ediel_mscons mscons/int isu_comev_ediel_mscons_int_in int_in_act
isu_ediel_mscons mscons/usg isu_comev_ediel_mscons_usg_in usg_in_act
isu_usage_data
Corresponds to EDI 867
isu_monthly_usage_information isu_comev_IDoc_inbound_usage usg_in_act
isu_usage_data
Corresponds to EDI 867
isu_monthly_usage_simulation isu_comev_IDoc_inbound_usage usg_in_act
isu_usage_data
Corresponds to EDI 867
isu_usage isu_comev_IDoc_inbound_usage
isu_comev_IDoc_isu_usage
usg_in_act
ediel_prodat prodat isu_comev_ediel_prodat_in req_uinfo, res_uinfo,
req_enroll, res_enroll,
req_drop, meter_chnd,
req_change
isu_general_reqest_response
Corresponds to EDI 814
isu_change_request isu_comev_IDoc_inbound_request req_change
isu_general_reqest_response
Corresponds to EDI 814
isu_drop_request isu_comev_IDoc_inbound_request req_drop
isu_general_reqest_response
Corresponds to EDI 814
isu_enrollment_request isu_comev_IDoc_inbound_request req_enroll
isu_general_reqest_response
Corresponds to EDI 814
isu_request isu_comev_IDoc_isu_request req_volntr, req_drop,
req_husage, res_enroll,
req_oc_mr, req_enroll,
req_enr_mr,
req_change,
req_metinf, req_reinst
isu_contract_payment
Corresponds to EDI 568
isu_contract_payment_in isu_comev_IDoc_isu_contr_paym cp_mis_pay,
cp_mis_rev,
cp_cus_cre, cp_cus_rev
isu_request_response
Corresponds to EDI 814
Caution
Not in se


SAP AG .....
..... Page 146 of 153

Cookbook
Intercompany Data Exchange


IDoc type Message type/code Event module Event(s)
Not in use
isu_invoice_4010
Corresponds to EDI 810, version
4010
isu_bill_information_4010 isu_comev_IDoc_isu_invoice inv_inbnd
isu_remittance_advice
Corresponds to EDI 820
isu_remittance_advice isu_comev_IDoc_isu_remitt_adv rem_adv_in
isu_maintenance_service_order
Corresponds to EDI 650
isu_maint_so isu_comev_IDoc_isu_maint_so rec_srvreq
Caution
Missing
Caution
Missing
isu_comev_ediel_aperak_in aperak_in


SAP AG ..... Page 147 of 153

.... Cookbook

12.6 Scenarios
A scenario is identified by the services and installations defined for the point of delivery and the
content of certain fields in these data objects.
The table below lists the scenarios supported by scenario determination ISU_IDE_SCENARIO,
which are defined in the function module ISU_IDE_SCENARIO_DEFINE. Scenarios are defined
independently of the service provider who acts as distributor or supplier. The scenarios only make a
distinction between service providers managed in the system and third party service providers or
between their service types, so that scenario definitions are valid both in a distributors and in a
suppliers system.
The table lists the identifying data environment for each scenario (some scenarios allow for several
alternatives). The following information is listed for each data environment:
Data objects defined for the point of delivery (services and installations)
Field contents for data objects
o Service providers in the contract or NB service
o Service type of NB service or installation
o Service provider that invoices the contract
o Payment class in contract or NB service
The payment class is allocated in the Customizing settings for the payment
method (advance payment, customer payment, sole provider). The payment
method is decisive in scenario determination.
The payment class must always be entered in contracts if the service provider
is different from the service provider that invoices the contract and one of the
two is managed in your own system.
o Service provider that bills the installation

SAP AG ..... Page 148 of 153

.... Cookbook
Intercompany Data Exchange


Scenario description

Data object

Field contents for
Service Provider
Service type Serv.prov.that
invs contract
Payment class Serv.prov.that
bills installation
Contract Serv.prov.
managed in own
system
Serv.prov.
managed in own
system
<blank>
Installation Own service
type
Serv.prov.
managed in own
system
Sole Provider

Invoicing for a third party service
provider

CO_SP_OWN = '0003'
NB service Third party service
provider
Third party
service type

Payment method
Sole Provider,
payment class
with regard to
third party
service provider

Contract Serv.prov.
managed in own
system
Third party
service provider
Payment method
Sole Provider,
payment class
with regard to
third party
service provider

Installation Own service
type
Serv.prov.
managed in own
system
Sole Provider

Invoicing by a third party service
provider

CO_SP_OTHER = '0004'
NB service Third party service
provider
Third party
service type
<blank>
Contract Serv.prov.
managed in own
system
Serv.prov.
managed in own
system
<blank> Billing Agent, Bill Ready

Invoicing for a third party service
provider

CO_BA_BILLREADY_OWN =
'0005'
Installation Own service
type
Serv.prov.
managed in own
system

SAP AG .....
..... Page 149 of 153

Cookbook
Intercompany Data Exchange


Scenario description

Data object

Field contents for
Service Provider
Service type Serv.prov.that
invs contract
Payment class Serv.prov.that
bills installation
Contract Third party service
provider
Serv.prov.
managed in own
system
Payment method
Billing Agent,
payment class
with regard to
third party
service provider
'0005'
Installation Third party
service type
Third party
service provider
Contract Serv.prov.
managed in own
system
Third party
service provider
Payment method
Billing Agent,
payment class
with regard to
third party
service provider


Installation Own service
type
Serv.prov.
managed in own
system
Billing Agent, Bill Ready

Invoicing by a third party service
provider

CO_BA_BILLREADY_OTHER =
'0006'
NB service Third party service
provider
Third party
service type
<blank>
Contract Serv.prov.
managed in own
system
Serv.prov.
managed in own
system
<blank> Billing Agent, Rate Ready

Billing and invoicing for a third
party service provider

CO_BA_RATEREADY_OWN =
'0007'
Installation Own service
type
Serv.prov.
managed in own
system

SAP AG .....
..... Page 150 of 153

Cookbook
Intercompany Data Exchange


Scenario description

Data object

Field contents for
Service Provider
Service type Serv.prov.that
invs contract
Payment class Serv.prov.that
bills installation
Contract Third party service
provider
Serv.prov.
managed in own
system
Payment method
Billing Agent,
payment class
with regard to
third party
service provider
'0007'
Installation Third party
service type
Serv.prov.
managed in own
system
Contract Serv.prov.
managed in own
system
Third party
service provider
Payment method
Billing Agent,
payment class
with regard to
third party
service provider

Installation Own service
type
Third party
service provider
Billing Agent, Rate Ready

Billing and invoicing by a third
party service provider

CO_BA_RATEREADY_
OTHER = '0008'
NB service Third party service
provider
Third party
service type
<blank>
Contract Serv.prov.
managed in own
system
Serv.prov.
managed in own
system
<blank>
Installation Own service
type
Serv.prov.
managed in own
system
Dual

Each service provider performs
their own billing and invoicing.

CO_DUAL = '0002'
NB service Third party service
provider
Third party
service type
<blank>

SAP AG .....
..... Page 151 of 153

Cookbook
Intercompany Data Exchange


Scenario description

Data object

Field contents for
Service Provider
Service type Serv.prov.that
invs contract
Payment class Serv.prov.that
bills installation
Contract Serv.prov.
managed in own
system
Serv.prov.
managed in own
system
<blank>
Installation Own service
type
Serv.prov.
managed in own
system
Contract <blank> <blank> <blank>
Regulated
No deregulation!

CO_REGULATED = '0001'
Installation <blank> <blank>
Contract Grid service
provider managed
in own system

Supplier service
provider
managed in own
system
<blank>
Installation Service type
grid
Supplier or grid
serv.prov.
managed in own
system
Contract Supplier service
provider managed
in own system
Supplier service
provider
managed in own
system

<blank>
Billing Agent

Both service providers
(distributor and supplier) are in
the same client.

CO_BA_OWN_OTHER_
OWN_LOG_SYS = '0009'
Installation Service type
supply
Supplier service
provider
managed in own
system

SAP AG .....
..... Page 152 of 153

Cookbook
Intercompany Data Exchange


Scenario description

Data object

Field contents for
Service Provider
Service type Serv.prov.that
invs contract
Payment class Serv.prov.that
bills installation
Contract Grid service
provider managed
in own system

Grid service
provider
managed in own
system
<blank>
Installation Service type
grid
Grid service
provider
managed in own
system
Contract Supplier service
provider managed
in own system
Grid service
provider
managed in own
system
<blank>

Installation Service type
supply
Supplier or grid
serv.prov.
managed in own
system
Contract Grid service
provider managed
in own system
Grid service
provider
managed in own
system
<blank>
Installation Service type
grid
Grid service
provider
managed in own
system
Dual

Both service providers
(distributor and supplier) are in
the same client.

CO_DUAL_OWN_OTHER_
OWN_LOG_SYS = '0010'
Contract Supplier service
provider managed
in own system
Supplier service
provider
managed in own
system
<blank>

SAP AG .....
..... Page 153 of 153

Cookbook
Intercompany Data Exchange


Scenario description

Data object

Field contents for
Service Provider
Service type Serv.prov.that
invs contract
Payment class Serv.prov.that
bills installation
Installation Service type
supply
Supplier service
provider
managed in own
system