Skip to end of metadata
Go to start of metadata

The Market Communication ES bundle provides companies in the utilities industry with the enhanced functionality and Enterprise Services they need to run business processes in the liberalized energy market. Liberalization within the utilities industry means that a number of different market parties who must interact with each other in various business processes, such as registering for and canceling access to energy grids, billing for services, and exchanging technical master data.

The liberalization of the European energy markets enforces the splitting of the formerly integrated utility companies into different market participants with their own tasks and responsibilities. In conjunction with liberalization, the number of market participants is increasing who are becoming more and more specialized. As a result, the utilities industry is evolving and its business processes are changing. Each of these market participants deploys different business models.

This evolution can only be mapped by providing the appropriate modeling of the market. This is in particular done in the etso/ebIX Market Role Model.

Market roles provide an excellent way of handling utilities liberalization. By dividing up functionality according to market roles, this ES bundle provides the required enterprise services from the viewpoint of individual market roles. Because roles are critical to understanding this ES bundle, here is a short definition of some central market roles:

  • Metering Point Administrator: Utilities service provider responsible for maintaining master data of utilities point of delivery (that is, the premises where the service is delivered)
  • Balance Supplier: Utilities service provider that supplies balance (which in this context means variable) power or gas to the energy consumer, having a supply contract with the energy consumer. The Balance Supplier is the central role from the perspective of the customer. It is the retail company with which the utilities customer has a relationship and from which the customer will receive bills
  • Grid Access Provider: Utilities service provider responsible for providing grid usage service for energy consumption or production to the party connected to the grid (usually consumer or producer of energy)
  • Meter Administrator: Utilities service provider responsible for keeping a database of meters and supplying other roles with technical device information and device locations
 

Market Communication (click to enlarge)


The first version of this ES bundle, delivered with Enhancement Package 4, delivers services with a focus on the Balance Supplier, the Metering Point Administrator, and the Meter Administrator.
The Market Communication ES bundle enables customers in the utilities industry to:

  • Create optimal integration of ERP processes and market communication
    • Business objects and service operations are specific to the utilities industry
    • Cutting-edge business semantics enable services to integrate with partner products
    • Service operations are oriented toward ebIX harmonized role model specifications
  • Combine different levels of modeling to achieve highly flexible process modeling capabilities
    • SAP Business Workflow (for use with existing ERP process logic)
    • BPM process modeling (for consuming enterprise services via SAP NetWeaver)
    • Composite Application Framework (for integrating enterprise services and composite applications)
    • Guided Procedures (for processes driven by user interfaces)
  • Work with process-oriented enterprise services for the utilities industry based on dedicated market roles
    • Highly comprehensible to business process analysts
    • Adaptable to existing partner solutions (EDIFACT adapters and so on)
    • Suitable for mapping to market messages as described by ebIX
  • Use XML as an open communication standard
    • Achieving optimal integration for system and market communication among SAP and non-SAP products

The Market Communication ES bundle leverages enterprise SOA through integration between SAP Process Integration (SAP PI) and SAP for Utilities.

Audience

All organizations in the liberalized utilities industry will find the Market Communication ES bundle useful.

Companies in the utilities industry that can use this bundle include:

  • Retail companies
  • Distribution companies
  • Metering companies

    For information about Service Operations, Business Objects and Process Components, see the ES Workplace.

     

How To Use This ES Bundle

This ES bundle helps service-enable SAP for Utilities. As a result, SAP for Utilities users may find this table of terms helpful:

SAP for Utilities Object

Business Object

Switch Document

Utilities Grid Usage Request ("request form," "Bestellschein")

Switch

Utilities Grid Usage Document

Document

("delivery note," "Lieferschein")

PoD

Utilities Point of Delivery

Settlement Unit

Utilities Energy Settlement Unit

IS-U grid

Utilities Grid

Business Partner

Business Partner

Service provider

Utilities Service Provider

Connection Object

Installation Point (standard ERP)

Premise

Not represented in business object model,
but premise-related data is assigned to Utilities Point of Delivery

Installation

Not represented in business object model,
but contract and billing relevant information
is assigned to the Utilities Contract while
technical and settlement-related information
is assigned to the Utilities Point of Delivery

Device, device info record

Utilities Device

Register

Utilities Measurement Task

Data exchange task

Utilities Tracked Business Transaction

Profile

Utilities Time Series

Due to their design, the Enterprise Services in this bundle fall into one of the following groups: asynchronous services that support market messages and synchronous services designed for creating composite applications. These enterprise services have different characteristics, as shown below.

Group 1: Asynchronous enterprise services for market messages

These enterprise services have the following characteristics:

  • Application in market processes with other market partners designed for use by dedicated market roles
  • Asynchronous
  • Many business objects
  • Relatively large, process-oriented interfaces that support a mapping to frequently used message formats

The highly standardized and agile services in the Market Communication ES bundle reflect current business semantics and take a market-role approach for modeling the changing landscape of the utilities industry. Additionally, used in conjunction with SAP NetWeaver Process Integration (SAP NetWeaver PI), third-party composite applications can provide detailed content relevant to specific countries and their latest regulations.

 

Market Communication ES bundle System Landscape (click to enlarge)


Enterprise services in this group include:

  • Request Utilities Grid Usage Request Creation  (1a Outbound registration request of BS)
  • Create Utilities Grid Usage Request  (2a Inbound registration request at MPA)
  • Confirm Utilities Grid Usage Request Creation (3a Outbound confirmation of MPA)
  • Change Request based on Utilities Grid Usage Request Creation Confirmation (4a Inbound confirmation at BS )
  • Request Utilities Grid Usage Request Cancellation (1b,c Outbound cancellation request of BS)
  • Cancel Utilities Grid Usage Request (2b,c Inbound cancellation request at BS or MPA)
  • Confirm Utilities Grid Usage Request Cancellation (3b,c Outbound cancellation confirmation of BS or MPA)
  • Change Request based on Utilities Grid Usage Request Cancellation Confirmation (4b,c Inbound cancellation confirmation at BS)
  • Notify of Utilities Grid Usage Document Usage Enrollment (5 Outbound Enrollment notification of MPA)
  • Change based on Utilities Grid Usage Document Usage Enrollment Notification (6 Inbound Enrollment notification at BS)
  • Notify of Utilities Grid Usage Document Usage Termination (7 Outbound Termination  notification of MPA)
  • Change based on Utilities Grid Usage Document Usage Termination Notification (8 Inbound Termination notification at BS)
  • Query Utilities Point Of Delivery by External Identification (Inbound query at MPA)
  • Respond Utilities Point Of Delivery by External Identification (Outbound response of MPA)
  • Query Utilities Point Of Delivery Measurement Task by External Identification (Inbound query at MPA)
  • Respond Utilities Point Of Delivery Measurement Task by External Identification (Outbound response of MPA)
  • Notify of Utilities Contract Registration (Outbound notification of MPA)
  • Change based on Utilities Contract Registration Notification (Inbound notification at  BS)
  • Notify of Utilities Time Series ERP Item (Outbound notification of MDR)
  • Change based on Utilities Time Series ERP Item Notification (Inbound notification at GAP or BS) 

Group 2: Synchronous Enterprise Services for Building Composite Applications

Enterprise services in this group have the following characteristics:

  • Application in all kinds of composites
  • High reusability
  • Synchronous
  • Very granular and highly specialized functionality
  • Very lean interfaces

Enterprise services in this group include:

  • Find Utilities Point Of Delivery by Premise Address
  • Read Utilities Point Of Delivery Supply Scenario
  • Read Utilities Point Of Delivery Grid Assignment
  • Read Utilities Point Of Delivery Load Shape
  • Find Utilities Point Of Delivery by External Identification
  • Read Utilities Point Of Delivery Premise Data
  • Read Utilities Point Of Delivery Energy Settlement Unit Assignment
  • Find Utilities Point Of Delivery by Utilities Contract

Use Cases for the Market Communication ES Bundle

The following section explores a series of use cases for the Market Communication ES bundle. Each scenario shows how different outcomes can be achieved by using the Enterprise Services in different combinations. While these examples illustrate some of the ways that this ES bundle could be used, the intention is to show the flexibility and re-usability of these business objects and enterprise service operations so that you will have a clearer understanding of how to best deploy them in your own environment. This wiki is also a space for you to share knowledge and collaborate with others who are implementing the Market Communication ES bundle.

Please note that the use cases may describe users directly invoking enterprise services; services are called by a composite application. This convention is used to illustrate the process flow. Please also note that no composite application or any kind of user interface is delivered with this ES bundle.

Use Case 1: The Balance Supplier Requests Master Data from the Metering Point Administrator

In the liberalized utilities industry, the party that supplies end customers with their gas or electricity is known as the Balance Supplier.

Another role is in charge of maintaining master data about the premises to which energy is delivered, referred to by ebIX, the European forum for Energy Business Information exchange, as the metering point. For this reason, the role in charge of master data for metering points is called the Metering Point Administrator. (In enterprise SOA terminology, the metering point is called the Utilities Point of Delivery.)

Typically, the point of delivery is based on different items of master data - the address of the residence or business consuming the energy, the external identification used within the market communication, the division category, the serial number of the physical meter that is located at the consumer's address, and so on.

In this use case, the Metering Point Administrator provides the master data to the consumer of the information, the Balance Supplier.

This use case describes the process by which a Balance Supplier requests and receives master data about the point of delivery from the Metering Point Administrator. This is usually done prior to delivering energy to the end customer.

To start, the Balance Supplier enters some information provided by the customer, for example, the address and meter number, into the composite application provided by the Metering Point Administrator. The composite application may consume several enterprise services out of this bundle to read step-by-step information from their database. This step-by-step approach is now described in more detail.

Entering the address information invokes the Find Utilities Point Of Delivery by Premise Address service operation, which uses the Utilities Point Of Delivery business object. This service pinpoints the Metering Point Administrator's external identifier for that particular point of delivery; the composite application can proceed with this external identifier to retrieve additional information. However, this functionality of identifying the point of delivery and providing its external identifier is so essential that this could be already a service offered to the market, for example to Balance Suppliers.

The next step consists in retrieving the internal identifier of the Utilities Point Of Delivery by using the external identifier, invoking the Find Utilities Point Of Delivery by External Identification service operation, which uses the Utilities Point Of Delivery business object. The internal identifier is required by the subsequently called Enterprise Services as input in order to retrieve data directly from the database of the Metering Point Administrator.

The composite provides information about the parties related to the Utilities Point Of Delivery, along with any other information that is relevant to communication and shared processes. In addition to the Metering Point Administrator and the Grid Access Provider, these parties may include the following:

  • Metered Data Responsible: The party in charge of validating meter data, calculating consumption values, and providing these values to all parties that need this information to perform billing and invoicing based on consumption
  • Metered Data Aggregator: The party that determines how much energy is consumed by all of the customers receiving services from a single Balance Supplier (while a single distribution grid may supply millions of end consumers with energy, hundreds of different Balance Suppliers may serve as intermediaries who receive the energy from the grid and deliver it to consumers)
  • Meter Administrator: The party that keeps a database of meters and supplies other related parties with technical device information and device location
  • Other market roles may also be relevant

To retrieve this data, the composite application can invoke the Read Utilities Point Of Delivery Supply Scenario service operation.

The composite application may retrieve data about the grid from which this Utilities Point Of Delivery receives its energy by triggering the Read Utilities Point Of Delivery Grid Assignment service operation.

For each day, the Balance Supplier must prepare a schedule that considers the energy provision and consumption for the following day. Later on, after energy has been consumed, the Metered Data Aggregator calculates the total consumption of all customers supplied by the Balance Supplier. This entails a description of the behavior of all of the customers to whom the supplier provides energy, which is known as a "synthetic load shape." This load shape may represent the consumption of a family household, a bakery, a farm, or a commercial warehouse, to name just a few examples. All of these load shapes, created and maintained by the Metered Data Aggregator, are taken into account when determining the following day's schedule. To view the load shape associated with this Utilities Point Of Delivery, the composite invokes the Read Utilities Point Of Delivery Load Shape service operation, allowing the Balance Supplier to assess the consumption patterns of this location over time.

The composite application returns the information retrieved to the Balance Supplier who can now use it directly for subsequent processes. The Balance Supplier could integrate this composite application with the CRM screens to provide optimal access for front office agents.

The following table summarizes these steps and the associated enterprise services:

Business steps

Enterprise Service Invoked

Step 1: The Balance Supplier enters customer information into the composite application to access additional information. This initiates a sequence of enterprise services.

Find Utilities Point of Delivery by Premise Address

Step 2: The composite application then retrieves the internal identifier of the customer by using an external identifier to access data from the Metering Point Administrator's database.

Find Utilities Point of Delivery by External Identification.

Step 3: The composite application then retrieves data related to the various parties (service providers) associated with the customer's account.

Read Utilities Point of Delivery Supply Scenario

Step 4: The composite application retrieves data related to the grid that services the customer.

Read Utilities Point of delivery Grid Assignment

Step 5: The composite application retrieves the typical usage profile (Synthetic Load Shape) of the customer.

Read Utilities Point of Delivery Load Shape

Step 6: To conclude, the composite application returns the above collected information to the Balance Supplier who then uses it in subsequent processes.

(no enterprise service is invoked during this step)

Use Case 2: The Balance Supplier Requests Technical Master Data from the Meter Administrator

In the previous use case, the Balance Supplier requested master data from the keeper of master data for each premises: the Metering Point Administrator.

Part of the master data the Balance Supplier retrieved was all the service providers connected to this utilities point of delivery. One of those is the Meter Administrator, the role in charge of managing the physical meters that are measuring energy consumption at the utilities point of delivery. The Balance Supplier now contacts the Meter Administrator to retrieve detailed information about the devices at the point of delivery.

As a prerequisite, the Balance Supplier must have the external identifier of the point of delivery as described in use case 1.

The next step consists in retrieving the internal identifier of the Utilities Point Of Delivery by using the external identifier as input to the Find Utilities Point Of Delivery by External Identification service operation, which uses the Utilities Point Of Delivery business object. The internal identifier is required to retrieve data directly out of the database of the Metering Point Administrator.

The next query pertains to correlating an object in the system - known as a "utilities measurement task" - to the physical devices that are installed at the point of delivery. This is important because, among other things, the supplier has to take these details into consideration when determining a suitable product for the customer, such as a product for on-peak and off-peak measurements. To find the utilities measurement task, the supplier can trigger the Query Utilities Point Of Delivery Measurement Task by External Identification service operation, which also uses the Utilities Point Of Delivery business object.

The next steps consist in identifying the devices for each measurement task by invoking Find Utilities Device by Utilities Measurement Task and retrieving device-related data by invoking Read Utilities Device Basic Data.

The composite application now returns the retrieved information to the Balance Supplier who can use it for subsequent processes.

The following table summarizes these steps and the related enterprise services:

Business steps

Enterprise Service Invoked

Step 1: As in Use Case 1, the Balance Supplier must provide the external identifier of the customer.

(no enterprise service is invoked during this step)

Step 2: The composite application retrieves the internal identifier of the customer by using the external identifier as the input.

Find Utilities Point of Delivery by External Identification

Step 3: Once verified, the composite application is able to access data from the Metering Point Administrator's database.

(no enterprise service is invoked during this step)

Step 4: The composite application must retrieve the correct utilities measurement tasks for the customer's devices.

Query Utilities Point of Delivery Measurement Task by External Identification

Step 5: The composite application will identify the devices related to each measurement task.

Find Utilities Device by Utilities Measurement Task

Step 6: The composite application will then retrieve the device related data.

Read Utilities Device Basic Data

Step 7: The composite application will return the retrieved information to the Balance Supplier who will use it for subsequent processes.

(no enterprise service is invoked during this step)

Use Case 3: Registering for Grid Usage (Balance Supplier)

Once a Balance Supplier has secured a contract with a new end consumer for the delivery of energy the supplier must submit a request to the Metering Point Administrator for access to the energy grid. Before granting the request, the Metering Point Administrator first executes a series of validations and checks. The process entails the exchange of several messages between the Balance Supplier, the Metering Point Administrator, and, frequently, a number of other related parties.

To begin the registration process, the Balance Supplier submits a request for use of the energy grid to the Metering Point Administrator by invoking an outbound enterprise service operation, Request Utilities Grid Usage Request Creation, which uses the Utilities Grid Usage Request business object.

In the final step of the registration process, the Balance Supplier receives a notice with the result of the initial request, either an approval or a rejection. The Balance Supplier receives this notice by invoking an inbound enterprise service operation, Notify of Utilities Grid Usage Document Usage Enrollment, which uses the Utilities Grid Usage Document business object.

 

Enterprise services for enrollment of grid usage (click to enlarge)

 

The termination of grid usage is a very similar use case. Instead of enrollment notification (Notify of Utilities Grid Usage Document Usage Enrollment), a termination notification (Notify of Utilities Grid Usage Document Usage Termination) is sent.

The following table summarizes these steps and the associated enterprise services:

Business steps

Enterprise Service Invoked

Step 1: The Balance Supplier submits a request to access the grid via the composite application.

Request Utilities Grid Usage Request Creation

Step 2: The Metering Point Administrator's system issues a confirmation that the request was received.

Confirm Utilities Grid Usage Request Creation

Step 3: The Balance Supplier receives notice of the result.

Notify of Utilities Grid Usage Document Usage Enrollment

Use Case 4: Processing a Request for Grid Usage enrollment (Metering Point Administrator)

As described in use case 3, the Metering Point Administrator receives all requests for use of the energy grid by Balance Suppliers. Once the Metering Point Administrator has received these requests and then sent an acknowledgment based on the results of preliminary checks, it can begin a validation process that abides by a number of rules established by various regulatory bodies. As part of the process, the Metering Point Administrator notifies all related parties that the request has been submitted and is undergoing validation. Among these parties, for instance, are the end consumer's former Balance Supplier and the Grid Access Provider who offers grid access to the Balance Supplier for supplying the end consumer with energy.

The Metering Point Administrator receives a request for use of the energy grid by a Balance Supplier via an inbound enterprise service operation, Request Utilities Grid Usage Request Creation, which uses the Utilities Grid Usage Request business object. Once it has determined that the request can be processed, the administrator sends a notice to the supplier by triggering an outbound enterprise service operation, Confirm Utilities Grid Usage Request Creation.

In the last phase of the process, after the request has received all validations and authorizations and the waiting period has ended, the Metering Point Administrator sends a message that notifies the Balance Supplier, the Grid Access Provider, and any other related party that the supplier is now registered to supply energy to the end consumer. The message is sent by invoking an outbound enterprise service operation, Notify of Utilities Grid Usage Document Usage Enrollment.

The termination of grid usage is very similar. Instead of enrollment notification (Notify of Utilities Grid Usage Document Usage Enrollment), a termination notification (Notify of Utilities Grid Usage Document Usage Termination) is used.

The following table summarizes these steps and the associated enterprise services:

Business steps - Metering Point Administrator

Enterprise Service Invoked

Step 1: The Metering Point Administrator receives a request for access to the grid.

Request utilities Grid Usage Request Creation

Step 2: The Metering Point Administrator issues a notice to the Balance Supplier that the request can be processed.

Confirm Utilities Grid Usage Request Creation

Step 3: Validations and etc. have been fulfilled and the Metering Point Administrator issues a notice to the relevant service providers that the Balance Supplier and customer are registered.

Notify of Utilities Grid Usage Document Usage Enrollment

Use case 5: The Metering Point Administrator notifies other market participants about new Meter Administrator

In highly liberalized utilities markets new types of market roles enter the market as separate players like Meter Administrator or Metered Data Responsible.

It now falls under the responsibility of the Metering Point Administrator as the central hub for master data to distribute master data changes to other market participants. In this use case the Meter Administrator at a customer's Point of Delivery has changed within a corresponding market process "Change-of-meter-responsibility".

The following table summarizes these steps and the associated enterprise services:

Business steps - Metering Point Administrator

Enterprise Service Invoked

Step 1: The Metering Point Administrator is notified market process "Change-of-meter-responsibility" about new Meter Administrator being responsible for a customers Point of Delivery.

(task of pre-process)

Step 2: The Metering Point Administrator maintains Point of Delivery master data to assign new Meter Adminstrator.

(no enterprise service is invoked during this step)

Step 3: The Metering Point Administrator send notification about master data changes at Point of Delivery

Notify of Utilities Contract Registration

Use case 6: Other market participants receive notification from the Metering Point Administrator about new Meter Administrator

Other market participants (e.g. Balance Suppliers) are notified about a newly assigned Meter Administrator at a customer's Point of delivery from the Metering Point Administrator. This information is required e.g. at a Balance Supplier to order meter market services at the correct market role or to communicate with the Meter Administrator electronically.

The following table summarizes these steps and the associated enterprise services:

Business steps - Receiver, e.g. Balance Supplier

Enterprise Service invoked

Step 1: A market participant like the Balance Supplier receives a notification from the Metering Point Administrator about a newly assigned Meter Administrator at a customer's Point of delivery.

Change based on Utilities Contract Registration Notification

Step 2: The recipient of the notification maintains Point of Delivery master data to assign new Meter Adminstrator.

(no enterprise service is invoked during this step)

Use case 7: The Metered Data Responsible notifies other market participants about interval measurement data

In highly liberalized utilities markets new types of market roles enter the market as separate players, such as the Metered Data Responsible. The Metered Data Responsible has to distribute measurement data to other market participants, such as the Grid Access Provider or the Balance Supplier.
In this use case, interval data (for example, 15 min intervals) is distributed to other market participants.

The following table summarizes these steps and the associated enterprise services:

Business steps - Metered Data Responsible

Enterprise Service invoked

Step 1: Schedule Data Exchange for Interval Data.

(no enterprise service is invoked during this step)

Step 2: Execute Data Exchange for Interval Data and send notification to other market participants.

Notify of Utilities Time Series ERP Item

Use case 8: Balance Supplier or other market role receive interval measurement data notification from the Metered Data Responsible

Other market participants (such as the Balance Suppliers) are notified about new interval measurement data on a regular basis (for example, daily). Balance Suppliers require this information for billing processes, settlement processes, forecasting processes and so on.

The following table summarizes these steps and the associated enterprise services:

Business steps - Receiver, such as a Balance Supplier

 

Step 1: Receive Interval Data via enterprise services on a regular basis.

Change based on Utilities Time Series ERP Item Notification

Step 2: Monitor received interval data.

(no enterprise service is invoked during this step)

Future Directions

Since the deregulation of the utilities industry is ongoing, corresponding business processes are in a state of flux. As a result, the solutions brought to bear on any aspect of the business must be as flexible, agile, and speedy as possible. SAP continues to work toward bringing such enhanced solutions to the market. Future directions for the Market Communication ES bundle include a number of possibilities for various market roles, including services designed to process requests for point of delivery master data, metered data, and device master data asynchronously. Services to request and receive measurement data are also being explored, as are services to send metered data, invoice for grid usage, and receive and verify grid usage invoices.

System Requirements

Related ES Bundles