This blog is a part of a series of blogs around SAP Industry Solution for Utilities. You can find the main blog here. In this blog, we will discuss about the IS-U data model. Understanding the data model is very important to configure and customize the SAP IS-U solution.
Before we proceed further, please read this fine print. All the views provided below are my personal opinion and doesn't necessarily reflect my employer's. I work for my employer as a Netweaver Integration consultant with a focus in Utilities Industry but every customer's requirement is unique and you should definitely seek for professional opinion before making your business decisions. Treat the inputs in this blog series as just opinions, nothing more, nothing less.
The IS-U master data model can be categorized in to two main groups
- Business Data
- Technical Data
Business Data: Any master data that is used for billing a customer for the services provided is grouped under Business data. For e.g., a business partner who is a person or an organization.
Technical Data: Any master data that is used for actually providing the services are grouped under Technical Data. For e.g., a device or a meter that is installed in a customer location.
Of course, the above definitions are highly simplified, so let's dig a little bit deeper. For the purposes of this discussion, I am conveniently leveraging the picture below from help.sap.com.
As you can see, the picture provides a visualization of the various data objects in IS-U with a perspective of an apartment complex. However, the relationship between the data models is the same, be it a commercial establishment or a single family house. So, let's first discuss the business data in this model
Business Partner: A business partner could be a person, an organization, a future customer, a contact person or even an installer who is licensed to provide the utilities services on behalf of the utility company. In most cases, it is easier to correlate the business partner with a human being with whom the utility business can conduct business. In case of an organization, it is imperative that some human is doing business with the utility on behalf of the organization.
Contract: A contract is the legal agreement that the business partner has entered with the utility for a particular service. For e.g., a utility may provide electricity, gas and water services. Usually a contract is created in the system for each of these services so that the customer can be billed appropriately. If you avail more than one service with your utility, take a minute to check your utility bill, you will see those contracts displayed separately as different line items in your bill.
Contract Account: A contract account is a logical way of grouping various contracts. The contract account is used for maintaining the payment, dunning and collection rules that are common to a group of contracts. It is through the contract account, the business partner is linked to the contracts. Multiple contracts can be grouped under a single contract account however, a contract can be linked only to one contract account. Also, multiple contract accounts can be linked to a business partner, however a contract account can only be linked to one business partner. In case of big commercial establishments or utility paid apartment complexes, the contract accounts may be used to group multiple suites or apartments under a single business partner, so that the payment responsibility lies with the business partner.
The combination of Business partner, contract account and contract comprise the business data. Now, let's look in to the technical data in the model.
Device: As obvious as it is, it refers to the physical device. It could be an electric meter, gas meter, regulator, sensor etc. Every device has a unique serial number and in SAP a utility device is a nothing but a equipment with a serial number. Every utility device will have a material number created in SAP as well. Usually each service (electric, gas, water) etc will have at the least one device. It is through the device reads that the utility can measure the consumption of the service.
Device Location: This refers to the physical location of the device. More than one device can be in a device location or each device can be its own location. For e.g., in my house, the gas meter is outside the house but the water meter is inside the house. So these would be treated as two device locations that have two individual devices installed. Device locations are handy to capture the co-ordinates so that when there is a maintenance activity to be performed on the device, it is easy for the field personnel to locate the device.
Connection Object: This refers to the physical location where the various services are provided. It is the service address and usually the address of the house but in case of apartment complex could be different than the address of the apartment that actually consumes the service. Device locations (discussed above) take the address of the connection object with additional qualifiers to pin point their location. For e.g., in my house, as I said, there are two device locations. The address of these locations will still be my house address but the additional qualifier would be basement, hallway etc. In SAP, the connection object is nothing but a plant maintenance functional location object.
Premise: This refers to the spatial unit or the enclosed structure to which the utility services have to be rendered. It is attached to the connection object and takes the address of the connection object but the premise also has other attributes attached to it. For e.g., in case of apartment complexes, you can attach the owner of the complex to the premise and when the premise is empty and if the services are still consumed, the apartment owner will be billed. The premise can also hold additional information about the spatial unit like if it's rental property, how many occupants etc. Note that this may sound like a duplicate of connection object, but there are some differences, because connection object is all about location data where premise is additional information about the actual structure and space within.
Installation: It is at the installation level various billing schema, rate tariffs and billing procedures are attached for the services provided. The installation groups various devices based on registers etc so that specific billing values like rate category can be maintained for the services. Also, every installation is attached to the premise so that actual supply point can be linkedwith the site where the services are provided. Point to note that is there is a one to one relationship between installation and contract.
Point of Delivery: This is a globally identified unique service point where a utility service is provided. In a deregulated market (a topic in itself), there are multiple service providers providing a customer different services. For e.g,, a utility company will be providing the actual electricity and any associated infrastructure around it whereas another provider will be able to provide billing, customer service and other related services. So, in a deregulated market, it becomes important to uniquely identify service point and it is done using the point of delivery data object. There is a 1:1 relationship between point of delivery and installation.
Device Category: This groups the various devices in to different categories based on the technical characteristics. This enables us to maintain the data that is common for a group of devices, there by grouping them in a logical way. Some examples of device categories are Meter, Transformer, Pressure regulator etc.
This summarizes the key master data objects that make up the IS-U data model. There are other data objects like Technical Installation, Connection, Grid and Services that are used for augmenting these key data objects. More information can be obtained here.
Of course there are many tables that hold data that relates to these data objects. Also, there is a tight integration between SAP CRM and SAP IS-U when it comes to front office processes (please refer the introduction blog for more information). Some of the master data is replicated between ECC and CRM. That is, these master data can be created first in either CRM or ECC and it is replicated to the other system as a part of the replication process. I have identified a separate blog on CRM replication and we will discuss about these nuances in detail there.
I am also working on interactive chart on various IS-U master data, transaction data and their relationships. Once done, I will either publish it as a separate blog or as a part of the blog identified for conversions.
Hopefully, this blog acts a starting point for understanding IS-U master data model. As always, input from the community is key to the quality of the content. So, please keep the comments coming.
- SAP Managed Tags:
28 Comments
