Skip to Content

I. Scope

The scope of this document is to capture the solution for the challenges faced by the business users in creating the SAP IS-U technical master data using standard SAP IS-U transactions. It provides only the guidelines for creating a tool to generate the SAP IS-U technical master data rather than getting into the details of developing the program. The SAP IS-U technical master data is explained in detail to facilitate the understanding of all the aspects of the solution.

II. Challenges faced by utility business users

The primary interests of the business users is in carrying out the day to day utility business transactions in SAP such as recording the utility consumption, billing the customer for the utility service etc. One of the prerequisite to carry out these business transactions is to have the technical master data in the system along with the other master data. However, creating the IS-U technical master data in SAP is not an easy task and the users have a tough time with it. Below mentioned are the challenges faced by the users in terms of creating the master data.

• Creating master data is a time consuming task as it involves numerous transactions.

• The users find it difficult to remember the transaction codes while creating the master data.

• The data objects are interdependent. Hence the users would have to follow the data hierarchy to create the correct set of master data. This makes the data creation work to be done only by the experienced users.

• The system generates a unique number for every data object created in the system. The users would have to keep track of these system generated numbers for every object, as it is required while creating subsequent objects in the system.

• Users find it difficult to relate the objects in SAP system with the real time business objects. Say for example, the object Device Location in SAP is referred as Meter Point Reference number in UK and EAN number in Denmark.

• There are certain specific values for objects which the user might not be aware at the time of data creation which otherwise can be defaulted, this can lead to data inconsistency. Eg: Billing values for the Installation.

III. Proposed solution

In order to address the concerns raised by the business users a custom transaction can be developed based on the ABAP module pool concept which creates the IS-U technical master data with the least possible input values.

IV. SAP IS-U technical master data – explained

The SAP IS-U technical master data is concerned about the technical objects required to supply the utility service at the customer’s location. It comprises of Connection Object, Premise, Installation, Point of Delivery and Device Location. In order to further explain the concept of full installation and how it can be achieved through programming the data object Device is explained. The point of delivery is not included in the explanation.


The below section explains these objects in detail.

Connection Object (Site):

Connection objects in SAP are usually physical locations where a utility service is provided.The Connection object is the highest object in the IS-U data hierarchy. It mainly stores address information, which is generally used as the supply address for utilities. It has many configurable address fields, which can be  used where required including; postal code, street name, house number, city (postal town), and several address line supplements. 

CO.JPG

Premise:

The Premise is referenced to the Connection object in SAP IS-U and can hold additional address information (where required). A Premise can have several utility installations (Supply Points / Contract Slices). The Premise is allocated to a Connection object and to the address of that Connection object.

PREMISE.JPG

Installation:

Utility installation represents the supply of utility services provided at a location. It is division-specific grouping of devices, registers and specific billing values that are allocated to a premise and that belong together for billing purposes.

An installation provides a single point of view for both metering and billing information. In SAP IS-U, billing is always done at the installation level. An installation groups together the devices that are allocated to the same site, and that are therefore billed together.

Device Location:

Device locations are locations / points where devices are installed and the consumption is measured. Device location in a connection object is where any number of devices can be installed.


The following are the general features of a Device Location

•General attributes can be recorded

•Status management is supported

•Authorizations can be set-up

•Metering service providers can be managed such as Meter read service provider.

DL.JPG

Device:

A Device is an instrument used for measuring consumption, processing data, or controlling and protecting other instruments.

Devices can be of following types:

• Record ( such as meters )

• Control ( such as isolation relay )

• Process data ( such as converters, data loggers )

• Protect ( such as pressure regulators )

A Device can also be termed as an asset, is a fundamental piece of equipment relevant to Gas Supply at a device location for a period of time.Examples: Meters, Converters, Data loggers, installation kits, meter boxes, bypasses etc. In SAP, devices are created in the system by referring to a device category.

The relation between the IS-U technical master data is shown below through a pictorial representation.The process of linking the device to installation and device location is called as Full Installation.

FI.JPG

V. Standard procedure for SAP IS-U technical master data creation

flow.JPG

VI. Technical aspects of the solution

The custom program uses the SAP standard function modules to create the IS-U technical master data.The details provided by the user are stored in the temporary data structures and used by the program during data creation.

Connection Object:


The address details and the instructions to create the connection object are passed to the importing parameter x_auto of the function module ISU_S_CONNOBJ_CREATE.The function module returns the created connection object.

co_fm.JPG

Premise:


The additional address details,the created connection object number, and the instructions to create the premise are passed to the importing parameter x_auto of the function module ISU_S_PREMISE_CREATE. The function module returns the created premise.


pre_fm.JPG

                          

Installation:


The installation attributes like installation type,supply guarantee, the rate category data and the instructions to create the Installation are passed to the importing parameter x_auto of the function ISU_INSTLN_CREATE.The function module returns the created installation.

Ins_fm.JPG


Device Location:


The connection object details are passed to the importing parameter x_auto of the function module  ISU_S_DEVLOC_CREATE.The function module returns the device location.


DL_fm.JPG


Device:


A device is created by specifying the material, division, company code, creation date etc to the function module ISU_M_EQUI_INSERT.

devi_fm.JPG


Note: For creating the device, the consecutive device serial number has to be passed to the function module ISU_M_EQUI_INSERT. This is fetched using the function module READ_MASE, this requires the material to be passed in the input.

Full Installation:


The device is linked to the device location and Installation through full installation. The function module used for this reason is ISU_S_WORKLIST_INSTALL. The device location, installation, date on which the activity should be performed, device serial number, equipment number, material, division etc are passed to the function module.

Passing a value ‘01’ to the parameter x_action of the function module indicates a full installation.

FI_fm.JPG


VII. Business benefits

Increase in productivity:

  • Saves 80% of time.

Easy to use:

  • One transaction does the job of many
  • Inter-dependency of the IS-U master data is taken care
  • Users can use the custom object with less expertise

Reduced data inconsistencies:

  • With minimal data entry, chances of data inconsistency is reduced to great extent

Custom validation:

  • We can incorporate the custom validations as per our requirements

Flexibility:

  • The data models of different countries can be mapped through the custom transaction
To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

    1. Mohammed Muzammil Post author

      Thanks for reading my article William and writing a comment.

      I have not had my hands on creating a MDT. It surprises me because I have seen these kind of custom master data generators being built in couple of projects I worked in the UK region. Could you please help me understand the reason why the solution team would have opted the custom development when the MDT solution was readily available?

      Meanwhile I shall speak to the solution architects of my previous projects and also read about the MDT’s.

      P.S: One more intent of writing this document was to help the SAP IS-U junior technical consultants with the information they might need in terms of the standard functions for creating the master data objects.

      Thanks.

      With Regards,

      Mohammed Muzammil.

      (0) 
      1. Uwe Radtke

        Addition to that – all mentioned function modules are marked as “internal”. Means no support by standard means if used within a customer report. All issues would have to be rebuild using the according BOR object methods.

        If the MDT is not known, how about FOPs ? Front office processes – it’s something like a guided procedure which you could develop calling the transactions mentioned above one after the other an passing the created data along.

        (1) 

Leave a Reply