Master Data Templates in SAP IS-U 

Purpose

Master data templates (MDTs) and the master data generator (MDG) are tools used in SAP IS-U to automatically create master data.

Business processes necessitate the creation of new utility services or changes to existing ones. Examples are:

·  Registration of a new customer with a service provider

·  Rate change that affects an existing customer

These utility services require you to create new data for objects from the data model or change existing data.

You can handle these business processes using IS-U transactions. These enable you to enter data in all the fields of the affected objects individually. This is often a lengthy and complex task.

You can accelerate this process by using a template application that allocates fixed values to fields in a given object. This restricts the number of fields that can be individually maintained. The system determines the fixed values from the context or type of utility service.

Examples of possible applications are:

·  Sales processes in Sales and Distribution (SD) or CRM

·  Internet Self Service functions

·  Exchange of data between a service provider and a distributor during a supplier change

·  Import of utility contracts concluded by a sales partner

This restricted view is supported by MDTs. If you want to use MDTs, you must execute the following steps:

  1.  Choose an autonomous standard SAP MDT category (MDT category) that matches the current business process. The MDT category determines what objects the system creates or changes.

  2.  Create an MDT for the MDT category. In the definition of the MDT, specify which fields are assigned a fixed value by the system and which fields you maintain yourself.

  3.  Integrate the MDG into your application. When the MDG is called, you transfer the individually entered values. The MDG adds the fixed values from the definition of the MDT to your values. It then uses all the values to maintain the corresponding objects of the IS-U data model.

When you execute a MDT, the system does not enter a master data key in the business partner object. Rather, the MDT and MDG enable you to make wide-ranging changes to objects from the IS-U data model with a minimum of data entry.  You can also use MDTs for initial data creation.

Example

You want to run an application to change a customer’s rate. To do this, proceed as follows:

  1.  Choose a suitable MDT category- in this case RATECHANGE. This MDT category is used to change data in the utility installation.

  2.  Create an MDT with this MDT category. In the definition of the MDT category, specify that the rate category of the utility installation is a fixed value. This means that all the installations to which this product is allocated receive this rate category. The system defines the changed date as a value that you maintain yourself.

  3.  From your application, call the MDG (ISU_PRODUCT_IMPLEMENT function module). Transfer both the key of the MDT and the values you entered to this function module. The function module then changes the utility installation in background.

The MDG is integrated in several IS-U applications, for example IS‑U Sales Processing. You can find further information in the documentation for SAP for Utilities in the Help Portal, under http://help.sap.com → SAP Industry Solutions → SAP for Utilities →Customer Service → IS-U Sales Processing.
As of Release 4.63, the MDG is used in the IS-U/CRM integration solution. For more information see the Help Portal, under http://help.sap.com → SAP Cross-Industry Solutions → SAP Customer Relationship Mgmt → SAP CRM 4.0 → Industry-Specific CRM → Service Industries → Utilities → Sales Processing for Residential Customers→ IS-U/CRM Integration: Sales Process for Residential Customers → Enhancements to the MDG for IS-U/CRM integration. This integration solution uses special MDT categories that are not described here.

To use IS-U sales processing you only need to create MDTs. The system calls the MDG automatically. If you are using applications that do not contain the MDG by default, you must integrate the ISU_PRODUCT_IMPLEMENT (process MDT) function module. This is very quick and simple to do. Use the ISU_MDATA_TEMPLATE_TEST (execute MDT) report for reference. The maintenance transaction for MDTs uses this report for testing purposes.

The graphic below shows you how to use the MDG in one of your own applications.

Notes:

·  The application calls the ISU_PRODUCT_IMPLEMENT function module. It transfers the key of the MDT and a list of values (name, address and so on) to the function module. These are used as the parameters of the MDT.

·  From the MDT and MDT category, the MDG infers the following:

o  Information on the IS-U master data to be changed/created.

o  Constant values with which the master data must be created.

o  Programs (scripts) for changing the master data.

If an error should occur, the master data generator terminates the template processing, and generates a workflow. The following documentation does not go into further details regarding the scenarios that use the master data generator. Instead, it describes the technical details of the MDT categories. This description should answer the following questions:

·  How do MDT categories and MDTs interact?

·  What master data can you create and change using the MDG?

·  What do I need to bear in mind when creating MDTs?

Master Data Template Categories 

Use

MDT categories determine the structure of MDTs. The MDT enables you to create and change IS-U master data using the MDG.

Features

Each MDT (hereafter called templates) is allocated to a MDT category (hereafter called template categories). The template category defines the following aspects of a template:

·  What master data the template can create (for example business partner, utility installation and so on)

·  What attributes (master data fields) can be maintained in the template (for example division or billing class of the utility installation and so on)

·  In what order the MDTs are created (for example connection object first, followed by premise and so on)

·  What programs are processed

·  What foreign key dependencies exist between individual items of master data, for example whether the premise adopts the key of the previously created connection object.

In contrast, the user maintains the following information in the template itself:

·  The values with which the master data is created.
Amongst other things, constants and parameters are differentiated here.

·  Whether to use the optional elements of the template (for example whether to create a connection object with or without a device location)

·  What parts of the template can be used more than once (for example whether business partners can be created with one or two addresses)

SAP supplies predefined MDT categories. They are stored in the EPDTYPE viewcluster (IS-U MDG: MDT category).

Template Category Hierarchy 

Definition

Template categories generally consist of several nodes. A node corresponds to a master data object, such as a premise, or to the characteristics of an object, such as the address of the business partner.

Structure

A hierarchy shows how the template category is divided into several nodes.

As of SAP IS-U Release 4.63, you can use transaction EPDHIER to display the hierarchy of a template category. As of Release 4.64 this display function is integrated in the master data maintenance transaction.

You can find this transaction in the IMG under SAP Utilities → Customer Service → MDG → Define MDT. On the initial screen enter the required MDT category and choose  Display Hierarchy. The table with the structure for the master data template category is displayed.

The BPARTNER (business partner) template category contains the template category BP_PAYMENT (business partner bank details) as a sub-node. The sub-nodes are indented, indicating the different hierarchy levels. The definition of the template category specifies that this node is optional. This means that when you create a template with this category, you can deactivate the node BP_PAYMENT. . If you do this, all the fields in the business partner relating to bank details remain empty. You can also replicate the node. You now have two of each bank details field to maintain. The system creates the business partner with two sets of bank details.

The BPARTNER template category also has the BP_ADDRESS sub-node (business partner address). BP_ADDRESS, in turn, has its own sub-nodes. Their position in the node hierarchy is indicated by a further indentation. If you activate BP_ADDRESS in the template then the sub-nodes of BP_ADDRESS are also activated. If you replicate BP_ADDRESS then the sub-nodes, such as BP_PHONE, are also replicated. The maintenance transaction for template categories displays the hierarchy by means of indentation, as explained above. The transaction also displays whether a node is active or inactive. You must make clear the template categories control these properties during maintenance.