5.- is-u master data templates.pdf

Stammdatenvorlagen zu Release 4.64

CookbookIS-U Master Data Templates

Cookbook Master Data Templates SAP AG

-2-

© Copyright 2003 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose withoutthe express permission of SAP AG. The information contained herein may be changed without priornotice.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registeredtrademarks of Microsoft Corporation.

IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®,OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®,Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USAand/or other countries.

ORACLE® is a registered trademark of ORACLE Corporation.

UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®,MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide WebConsortium, 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 technologyinvented and implemented by Netscape.

MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com, and other SAP products and services mentionedherein as well as their respective logos are trademarks or registered trademarks of SAP AG inGermany and in several other countries all over the world. All other product and service namesmentioned are the trademarks of their respective companies.

SAP AG Cookbook Master Data Templates

-3-

Icons

Icon Meaning

Caution

Example

Note


-4-

Master Data Templates Cookbook

ContentsIcons ..........................................................................................................................3

1 Master Data Templates..................................................................................................................61.1 Overview..............................................................................................................61.2 What Are Master Data Template Categories?........................................................9

1.2.1 MDTs and MDT Categories ............................................................... 91.2.2 MDT Category Hierarchy................................................................... 91.2.3 Cardinality ....................................................................................... 101.2.4 Autonomous MDT Categories.......................................................... 111.2.5 Create or Change.............................................................................. 111.2.6 Virtual Attributes ............................................................................. 121.2.7 User-Defined Fields ......................................................................... 13

1.3 Environment Determination................................................................................13ISU_ENVIRONMENT_PREMISE........................................................... 14General Information................................................................................ 14Environment for Technical Master Data.................................................. 14Identifying Constants .............................................................................. 14

1.4 Master Data Templates .......................................................................................151.4.1 Example........................................................................................... 151.4.2 Create and Test Master Data Templates............................................ 171.4 3 Notes on the Parameters ................................................................... 19

1.5 Master Data Generator........................................................................................211.5.1 Customer Contact............................................................................. 211.5.2 Key for New Master Data................................................................. 22

1.6 Error Handling in the Master Data Generator ......................................................221.7 Description of Master Data Template Categories ................................................22

1.7.1 NEWCUSTPOD .............................................................................. 221.7.2 NEWCUST...................................................................................... 231.7.3 RATECHANGE .............................................................................. 231.7.4 BPARTNER and CONTRACT_ACCOUNT.................................... 24

- BP_PAYMENT.................................................................................. 26- BP_CCARD ....................................................................................... 26- BP_TAXNUM.................................................................................... 26- BP_IND_SECTOR............................................................................. 26- BP_COPY_PREM_ADDR ................................................................. 26- BP_ADDRESS ................................................................................... 27- BP_PHONE........................................................................................ 27- BP_FAX............................................................................................. 28- BP_EMAIL ........................................................................................ 28

1.7.4.1 CONTRACT_ACCOUNT........................................................... 281.7.5 DEVICE_INFO and REGISTER_INFO........................................... 28


-5-

- DEVICE_INFO as of Release 4.64 ....................................................... 29- DEVICE_INFO until IS-U Release 4.63............................................... 331.7.5.1 REGISTER_INFO as of IS-U-Release 4.64................................. 33

1.7.6 QPRICE........................................................................................... 361.7.7. QPRICE_HIST ............................................................................... 36

Meaning of the Quantity Base ............................................................... 40QPRICE.............................................................................................. 41

CRM Prices .......................................................................................... 41LPRICE ................................................................................................ 41TPRICE ................................................................................................ 41

1.7.7 CONNOBJ....................................................................................... 421.7.8 DEVICE_LOCATION..................................................................... 421.7.9.1 DEVICE_TECH_INSTALL and REG_TECH_INSTALL........... 421.7.9.2 SERV_FREQ_SERV_LOC......................................................... 43

1.7.10 POD_STAND_ALONE ................................................................. 451.7.11 PREMISE ...................................................................................... 451.7.11.1 MOVE_IN ................................................................................ 46- MOVE_IN_BBP................................................................................. 47- MOVE_IN_MR.................................................................................. 48- MOVE_IN_SEC................................................................................. 49

1.7.11.2 INSTALLATION........................................................................ 51- INSTALLATION_HISTORY............................................................. 51Normal Installation Facts ...................................................................... 51

Reference Values .................................................................................... 58- LPROF_INST_ASSIGN and LPROF_INST_FACTOR...................... 59DEVICE_BILL_INSTALL and REG_BILL_INSTALL ....................... 61- LPROF_REG_ASSIGN...................................................................... 64- POINT_OF_DELIVERY.................................................................... 65- CONTRACT ...................................................................................... 65- BCONTACT ...................................................................................... 66

2 Master Data Templates in Release 4.64.......................................................................................672 Master Data Templates in Release 4.63.......................................................................................673 Master Data Templates in Release 4.62.......................................................................................684 Master Data Templates in Release 4.61.......................................................................................69

Master Data Template Categories ............................................................. 69Test Master Data Templates...................................................................... 69


-6-

1 Master Data Templates

1.1 OverviewMaster data templates (MDTs) and the master data generator (MDG) are tools used in IS-U toautomatically 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 providerRate change that affects an existing customer

These utility services require you to create new data for objects from the data model orchange existing data.You can handle these business processes using IS-U transactions. These enable you to enterdata in all the fields of the affected objects individually. This is often a lengthy and complextask.You can accelerate this process by using a template application that allocates fixed values tofields 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 CRMInternet Self Service functionsExchange of data between a service provider and distributor during asupplier 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 thefollowing steps:

Choose an autonomous standard SAP MDT category (MDT category)that matches the current business process. The MDT categorydetermines what objects the system creates or changes.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 whichfields you maintain yourself.Integrate the MDG into your application. When the MDG is called, youtransfer the individually entered values. The MDG adds the fixed valuesfrom the definition of the MDT to your values. It then uses all thevalues 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 partnerobject. Rather, the MDT and MDG enable you to make wide-ranging changes to objects fromthe IS-U data model with a minimum of data entry. You can also use MDTs for initial datacreation.


-7-

ExampleYou want to run an application to change a customer’s rate. To do this, proceed asfollows:

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

2. Create an MDT with this MDT category. In the definition of the MDTcategory, 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 thisrate category. The system defines the changed date as a value that you maintainyourself.

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

The MDG is integrated in several IS-U applications, for example IS-U sales processing. Youcan 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 CustomerService IS-U Sales Processing. As of Release 4.63, the MDG is used in the IS-U/CRMintegration solution. For more information see the Help Portal, under http://help.sap.comSAP Cross-Industry Solutions SAP Customer Relationship Mgmt SAP CRM 4.0Industry-Specific CRM Service Industries Utilities Sales Processing for ResidentialCustomers IS-U/CRM Integration: Sales Process for Residential CustomersEnhancements to the MDG for IS-U/CRM integration. This integration solution uses specialMDT categories that are not described in this cookbook.To use IS-U sales processing you only need to create MDTs. The system calls the MDGautomatically. If you are using applications that do not contain the MDG by default, you mustintegrate the ISU_PRODUCT_IMPLEMENT (process MDT) function module. This is veryquick and simple to do. Use the ISU_MDATA_TEMPLATE_TEST (execute MDT) report forreference. The maintenance transaction for MDTs uses this report for testing purposes.

http://help.sap.com/

http://help.sap.com/


-8-

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

SAP AG 2000 filename (author) / 1

The IS-U Master Data Generator

IS-Umaster

data

Template ID

Parameter

Masterdata

template

Masterdata

temp. cat.

Master datagenerator

ScriptsObject

Methods

Work-flow

Executingprogram

Figure 1: Operation of the IS-U Master Data Generator

Notes:The application calls the ISU_PRODUCT_IMPLEMENT functionmodule. 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 theparameters 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.The scripts use OO methods to create and change IS-U master data.

If an error occurs, the MDG cancels processing of the template and generates a workflow. Theinformation below does not describe any scenarios involving the MDG. Instead, it describesthe technical details of the MDT categories. It answers 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?


-9-

1.2 What Are Master Data Template Categories?

1.2.1 MDTs and MDT CategoriesMDT categories determine the structure of MDTs. The MDT enables you to create andchange IS-U master data using the MDG.Each MDT (hereafter called templates) is allocated to a MDT category (hereafter calledtemplate categories). The template category defines the following aspects of a template:

What master data the template can create (for example businesspartner, 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 soon)

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

What programs are processedWhat foreign key dependencies exist between individual items ofmaster data, for example whether the premise adopts the key of thepreviously 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 otherthings, constants and parameters are differentiated here.

Whether to use the optional elements of the template (for examplewhether to create a connection object with or without a devicelocation)

What parts of the template can be used more than once (for examplewhether 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)

1.2.2 MDT Category Hierarchy

Template categories generally consist of several nodes. A node corresponds to a master dataobject, such as a premise, or to the characteristics of an object, such as the address of thebusiness partner.A hierarchy shows how the template category is divided into several nodes.

NoteAs of Release 4.63, you can use transaction EPDHIER to display the hierarchyof a template category. As of Release 4.64 this display function is integrated inthe master data maintenance transaction.

You can find this transaction in the IMG under SAP Utilities Customer Service MDGDefine MDT. On the initial screen enter the required MDT category and choose DisplayHierarchy.


-10-

Figure 2: Hierarchy of the BPARTNER (business partner) template category

The above template category contains the sub-node BP_PAYMENT (business partner bankdetails). The sub-nodes are indented, indicating the different hierarchy levels. The definitionof the template category specifies that this node is optional. This means that when you createa 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 alsoreplicate the node. You now have two of each bank details field to maintain. The systemcreates the business partner with two sets of bank details.The BPARTNER template category also has the BP_ADDRESS sub-node (business partneraddress). BP_ADDRESS, in turn, has its own sub-nodes. Their position in the node hierarchyis indicated by a further indentation. If you activate BP_ADDRESS in the template then thesub-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 templatecategories displays the hierarchy by means of indentation, as explained above. The transactionalso displays whether a node is active or inactive. You must make clear the templatecategories control these properties during maintenance.

1.2.3 CardinalityThe cardinality of a MDT category determines whether the nodes in the template category canbe activated and deactivated. The cardinality of a template category can have one of thefollowing values:

0-1: The template category does not contain the node/the templatecategory contains the node once. It can be deactivated but not replicated.


-11-

0-n: The template category does not contain the node/the node can bereplicated any number of times. You can deactivate and replicate the node.

1: The template category can contain the node once only. The nodeis always active.

1-n: The template category can contain the node once, or replicatedany number of times. The node(s) can be replicated but not deactivated.

ExampleIn the BPARTNER template category, the BP_PAYMENT sub-node hascardinality 0-n. This means you can create a template with this category thathas a business partner with more than one set of bank details, or, alternatively,with no bank details.

NoteTo increase flexibility you mark the address nodes as dynamic. This means thatthe system only decides at the runtime whether to actually execute the node. Ifthe application calling the MDG can only supply one street and city asparameters then the system creates the business partner with only one address.For more information, see the field help of the Dynamic node category andDynamic execution-relevant attribute fields.

1.2.4 Autonomous MDT CategoriesYou can set an indicator that marks nodes as autonomous. Autonomous MDT categories areof particular importance since they can only be used in creating templates. They describe oneor more master data changes that can be executed in their own right. Non-autonomoustemplate categories form sub-nodes of other, autonomous template categories.

1.2.5 Create or ChangeEach template category contains programs for processing the template. The system calls theseprograms by means of the MDG. Most of these programs can create new master data andchange existing master data. Note that some template categories do not support a changemode.

ExampleThe template category used to install a device in an installation forbilling purposes does not have a change mode. This is appropriate sincethe corresponding dialog transaction cannot change data either.

Below, in the descriptions of the individual template categories, you can see whether aparticular category enables you to change master data objects. Use the attribute that containsthe key of the object to define whether you can execute the template in change or createmode.


-12-

ExampleThe BPARTNER template category (business partner) contains thePARTNER attribute (business partner number). With this field you cando one of the following:

In the template for the PARTNER attribute, choose the evaluationcategory Constant. Do not enter a value (the field remains empty).Result: Each time you execute the template, the system creates abusiness partner. The system allocates a key to the business partner.

In the template for the PARTNER attribute, choose the evaluationcategory Parameter. The application that calls the MDG allocates avalue to the parameter.Result: The system changes the business partner with the transferredkey value.

In the template for the PARTNER attribute, choose the evaluationcategory Parameter. The application that calls the MDG does notallocate a value to the parameter.Result: When you execute the template, the system creates a newbusiness partner.

NoteThe system does not support external number assignment.

If you use a template that can process several prices of master data then you cancreate and change master data objects simultaneously.

ExampleFor a new installation you change an existing utility installation (forexample, by allocating a new rate category) and create a new contract.

NoteThe master data generator does not support the deletion of objects. This alsoapplies for subobjects.For example: You can create or change one or more addresses for a businesspartner. However, you cannot delete an existing address.

1.2.6 Virtual AttributesUse the Virtual evaluation category for virtual attributes. The value is then determined at runtime. This task is executed by a user-defined function module, which you enter as an attributevalue in the template.Function modules for virtual attributes must have a pre-defined interface. For example, youcan use the function module ISU_VIRT_ATTR_REGIO_DEMO (demo solution: meter


-13-

reading unit as a virtual attribute) for your own solution. Note the documentation in the codefor this sample solution.

1.2.7 User-Defined FieldsSeveral template categories use an attribute beginning with #CI_. These attributes representuser-defined enhancement in the master data tables.

ExampleThe PREMISE template category contains the #CI_EVBS attribute. Itrepresents the CI_EVBS append-structure included in the EVBS table(premise).

If you do not create the CI_EVBS structure, the CI_EVBS attribute is inactive. This is not thecase if you include customer-defined fields for the premise in CI_EVBS. If you now create atemplate with the PREMISE category, the system offers the fields of the CI_EVBS structureas additional fields. This feature enables you to use the MDG to maintain user-defined fields.

1.3 Environment DeterminationOne MDT can be used for simultaneously creating and changing objects. This flexibility isimportant in sales processes, for example. You can use an MDT for initial data creation (tocreate premises, installations and so on), or to change existing objects for a customer (to enterthe rate category from a product sold to the customer in the installation, for example).The key transferred to the MDT determines whether the template creates an object (forexample a utility installation). If the ANLAGE attribute (key for the utility installation) in theINSTALLATION node is assigned a value at runtime, the installation in question is changed.If not, the system creates a new installation.The application that calls the master data generator can use the MDT parameters to definewhat is to be changed or created. However, MDTs can contain many objects: the connectionobject, premise, installations, devices and so on. The application called does not always knowall the objects. Furthermore, some objects may be replicated; there may be two devices (onand off-peak meters), two installations (one for the supplier and one for the distributor) and soon.This situation requires a function that identifies existing objects and allocates them to therespective nodes. We call this function environment determination.Example:

The MDT is only called with the key of the premise. If the premisealready has utility installations then the keys of these installations aredetermined.

The key is to be automatically allocated to the ANLAGE parameter ofthe INSTALLATION node.

It must be ensured that the existing installation of the distributor can bedistinguished from the existing installation of the supplier andallocated to the correct node. This is made possible by comparing


-14-

identifying constants in the MDT with the values in the respectiveinstallation.

There is no universal solution for this task. However, SAP provides two environmentdetermination functions that fulfill the above tasks in special applications:

ISU_ENVIRONMENT_PREMISE is run in the MDT categoriesNEWCUST, NEWCUSTPOD and RATECHANGE. It is only activeif you keep to the conventions of IS-U sales processing for Release4.62 on the SD platform.

ISU_MDG_READ_ENV_UI is run in the MDT categoryCRMNEWCONTRACT. It is used in the IS-U/CRM integrationsolution. For more information, see the cookbook Integration of SalesProcesses Between IS-U 4.63 and CRM 3.0 in the Servicehttp://service.sap.com. The information below is restricted toISU_ENVIRONMENT_PREMISE.

ISU_ENVIRONMENT_PREMISE

General InformationA utility product references a point of delivery, thereby referring to a utility installation. Thisis defined by the Influence master data field in the definition of the utility product.The MDT defines the modeling of a product in the IS-U data model. In the MDT, there is acomplete interface from which you can choose a subset. You can enter data in the subset. Youcan also refer to existing structures. To do this, ensure you specify the key of the affectedobject and that it is transferred to the corresponding key field.

Environment for Technical Master DataThe environment determination function is used in generating quotations and for the sale ofutility products. It finds existing structures and enters key from the corresponding parameterfields in the MDG. This ensures that existing objects are re-used.The NEWCUST, NEWCUSTPOD and RATECHANGE product categories contain theISU_ENVIRONMENT_PREMISE function module. This function module can search forobjects in the technical master data (such as installation, installation facts, devices, andregisters) belonging to a business partner or contract account.This module operates on two levels and can be used to define a device or register in the IS-Uinstallation found on the first level.

Identifying ConstantsIn the MDT, you can, after activating the environment determination function, create aparameter of the identifying constants category. This value defines the criteria by whichdifferent objects of the same category can be selected. Without this parameter, the systemcannot search for the objects.

http://service.sap.com./


-15-

Figure 3: Identifying constants in MDT maintenance

When you create the NEWCUSTOMER MDT, the system examines the data in the SERVICEfield and compares it with the entries in the technical master data for the business partner. Ifthere is a utility installation with the value 002 then the key of that installation isautomatically entered in the VSTELLE field.If there is more than one installation with this value then the system asynchronously proposesa dialog. This dialog allows the user to choose one of the objects found and resume theprocess at the point where it was interrupted.

1.4 Master Data Templates

1.4.1 ExampleBelow is an example of a MDT. Following this example is a description of the individualMDT categories. The example explains the links between template categories and templates.The NEW_PARTNER MDT was created with the BPARTNER template category. Thistemplate creates a business partner and a contract account.


-16-

Figure 4: Create NEW_PARTNER master data template

Note the upper left side of the screen. Using the Activate node and Double node (replicate node)pushbuttons, as well as the cardinality of the template category, the following hierarchy hasbeen created:

The optional Bank details node was not activated. This means that thebusiness partner was created without a set of bank details.

The Address node was activated once.The Telephone number sub-node was replicated. The system createsthe business partner with two telephone numbers. If these nodes aredynamic (dynamic nodes must have at least one attribute relevant toexecution of the node), you can suppress them at runtime.

The sub-nodes of Address, Fax and E-mail address were not activated.The Contract account is active.

On the right side of the screen you see the attributes of the CONTRACT_ACCOUNT node.They are as follows:

Contract account number (VKONT). This has the Parameterevaluation category. The Val. (value) column contains the VKONTparameter. The MDG therefore searches the parameter list for aparameter with this name. The value of this parameter is then adoptedby this attribute when you execute the template.


-17-

Since VKONT is a key field, an additional rule applies. If VKONT has aninitial value then the system creates a new contract account. If not then thesystem changes the contract account using the transferred key.

Contract account name (VKBEZ). The system assigns the attributename as the parameter name. You can give the parameter any nameyou want (the system proposes the contract name as a default value).VKBEZ is mandatory. Therefore, a value must be allocated externallyto the parameter VKBEZ.

The Business partner number (GPART) has the evaluation categoryKey reference. When you execute this attribute, the MDGautomatically allocates the key of the previously changed or createdbusiness partner.

Contract account category (VKTYP) and Tolerance group for contractaccount (TOGRU) are Constants. This means that all the contractaccounts created using this template are assigned the tolerance group0001.

The Contract account number (VKONA) attribute in the legacy systemhas the Do not change evaluation category. If an existing contractaccount is changed using this template, the contract account numberin the legacy system remains unchanged. If a new contract account iscreated, the contract account number in the legacy system remainsempty.

1.4.2 Create and Test Master Data TemplatesYou can find this transaction in the IMG under SAP Utilities Customer Service MDGDefine MDT.

NoteWhen you maintain the MDTs, we recommend that you open a second sessionto test the function you are using. For example, if you are creating a businesspartner, the test session enables you to view the content of individual fields anddetermine the fields to which default data can be successfully assigned.

This test (using the creation of a business partner as an example) has thefollowing benefits:- The function shows you the meaning of individual attributes, and what

attributes you can maintain. As a rule, the attributes in MDT maintenancecorrespond to those on the screen in the relevant master data function. Theattributes are also in the same order, though exceptions may occur. Forexample, if you enter a division in the master data function then the entries inother fields are affected.

- You can make use of the checks in the functions. For technical reasons youcannot check the constants in the maintenance transaction for the MDT.


-18-

- The master data function shows you what fields are mandatory. Themaster data function shows you what fields are mandatory. Attributes thathave fields marked with Mandatory (attribute is mandatory) may haveadditional fields whose entries are dependent on data in other fields.When you activate a node, the mandatory attributes are first given thestatus ‘red’. This shows the user that, as a rule, he/she requires a constantor a parameter for these attributes. However, you can also select Do notchange for mandatory attributes. The Mandatory indicator is only ageneral rule, which does have exceptions.

For example: The attributes for the first name and surname are mandatoryfor a business partner. However, if you use the template to create abusiness partner from the Organization category other attributes aremandatory. If you have any doubts, refer to the respective master datatransaction.

The maintenance transaction also enables you to test your MDTs. In the initial screen, choosethe Test template pushbutton to execute your template.First, the system edits the parameters of the MDT. Enter an appropriate value. You can leavenon-mandatory parameters empty.As of Release 4.72, the screen for editing parameters includes the pushbutton Active Nodes.You can use this pushbutton to gain an overview of the active nodes for the current masterdata template. This is particularly useful if the template contains dynamic nodes. Theoverview shows which nodes are executed when you select the parameters. It is possible tonavigate to the function module that is run when the master data generator is executed. This isdone by selecting the columns Open Script, Modify Script or Save Script. This allows you toeasily set breakpoints.As of IS-U Release 4.71, the pushbutton Copy Key is available. It is only available when yourecall the test function in the same mode. It copies the key created in a previous test run to theparameter of the same name. Example:

You execute a master data template of the categoryCRMPARTNERTECH. The attribute that belongs to the key of thepoint of delivery has the parameter name P_INT_UI. Amongst otherthings, the master data template creates a new point of delivery.Still in transaction EPRODCUST, you now select a template from thecategory CRMNEWCONTRACT. Here, the system uses the sameparameter name P_INT_UI for the key for the point of delivery.Select Copy Key. The system takes the key for the point of deliverycreated in the first run and transfers it for parameter P_INT_UI. Youmust no longer manually complete the parameter.

Note that the copy key function is only possible with identical names. There is no check to seewhether the parameters in the old and new runs have the same meaning. This function alsomakes it easier to test changes.


-19-

Use the pushbutton Transfer to complete the entry of parameter values. You are then requiredto confirm the execution.

Caution

When you test an MDT, the system creates or changes master data. Thesechanges cannot be reversed.

When the system has executed the MDT, you can use the functions listed below:The Log contains messages on all the master data objects that werecreated or changed. If an error occurred during execution, the logcontains information on the reason for the error.

The Flow information shows you a list of all the programs executed bythe MDG. You can navigate in the coding of these programs. Expertscan use this navigation to set break points in the coding. Icons indicatewhether each master data object was created or changed. An icon alsoindicates errors.

The Data environment shows you a list of the created and changedobjects. From this list you can branch to the data environment display.

The Workplace calls the business workplace. Here, you can re-edit theparameters of a canceled run (if an error occurred) and complete theexecution of the template.

1.4 3 Notes on the ParametersThe parameters used in the MDT are stored and evaluated in the template header data. If youare processing a material or utility product that has not yet been assigned to the header of thetemplate then you can only choose the parameter using the F4 of the field name or by enteringa parameter name.


-20-

Figure 5: After the assignment of a utility product/material to the master data template

The header data contains all the available parameters from the utility product as well as theparameter assigned from the template category. Once the utility product has been allocated,you can select the required sets of parameter using the F4 help and allocate them. You canthen define these parameters in Customizing. All the parameters from the utility product aredefined in the header data as external.The colors preceding the nodes denote the status of the node. They are as follows:

Green: Parameter assignedYellow: Parameter assigned several timesGrey: Parameter not yet assigned.

NoteFor the Create sales order transaction, use parameters from the utilityproduct/material only. Use the field names from the template category for testpurposes only.


-21-

Fig. 6: Maintain Master Data Templates

1.5 Master Data Generator

1.5.1 Customer ContactWhen you execute a template using the MDG, the system checks whether a business partneris linked to the template.

If the MDT contains a node with the BPARTNER category (businesspartner), the system identifies the relevant business partner.If not, the system searches for a node with the INSTALLATIONcategory. The system can determine a business partner from therelationship between the utility installation to the contract and contractaccount.

If a business partner can be identified by one of these two methods, the system creates acustomer contact once the master data has been changed.

Program context SAPLEPD_IMPLEMENT, sub-context ‘0001’.


-22-

If necessary, you can define the MDT to create additional customer contacts. See thedocumentation on the BCONTACT template category.

1.5.2 Key for New Master DataAfter the master data template has been executed, you can use the log to find out whichmaster data was generated. If, during subsequent processing, you need the keys for thegenerated or changed master data, you can use the export parameter XY_NEW_KEYS_TABfrom the function module ISU_PRODUCT_IMPLEMENT.The keys for the master data correspond with attributes in the master data template, in whichthe field KEYATTR Key Attribute is marked in the master data template category. For mostnodes, these keys are transferred in the table XY_NEW_KEYS_TAB. A prerequisite is thatyou select the data source type Parameter for these attributes.

1.6 Error Handling in the Master Data GeneratorVarious errors can occur when executing the master data generator, such as invalid parametervalues, blocked objects or templates that contain errors. For a description of the procedure inthe case of errors, see the cookbook Error Handling in SAP IS-U for Utility Contracts andTechnical Objects from CRM in the SAP Service Marketplace, www.service.sap.com. SelectLogin Now and then use your user name and password. Now select Solution DetailsIndustry Portfolios SAP for Utilities Product Information mySAP CRM for Utilities

Cookbooks&Guidelines -> Error Handling IS-U f. CRM Utility Contracts and Techn.Objects.

1.7 Description of Master Data Template CategoriesThe two most efficient master data template categories are:

NEWCUSTPOD for executing a new installation (as of Release 4.63)RATECHANGE for rate changes at an existing installation

As a rule, we recommend that you create master data templates with one of these templatecategories. All other independent template categories are contained as subnodes in thesecategories. However, you can also use the other independent template categories to definemaster data templates. In addition, several independent template categories exist, which areimportant for IS-U/CRM integration. This document does not give further details of thesecategories.

1.7.1 NEWCUSTPOD

NoteNEWCUSTPOD is the most comprehensive MDT category. You can useNEWCUSTPOD for initial data creation with the following objects:

Business partner and contract accountDevice information recordConnection object, device location, premise, point of deliveryUtility installation, installation facts

http://www.service.sap.com./


-23-

Technical device installation, billing-related device installation, deviceinfo records

Move-in, contract, business partner contractYou can use transaction EPDHIER to show the hierarchy for this template category. You cansee from the hierarchy that the cardinality supports a variety of scenarios.

You can recreate all the objects or use some of the existing objects, forexample create a new contract account for an existing business partner

You can deactivate any objects you do not require, such as unnecessaryinstallation facts, device locations and so on

You can replicate nodes- together with their sub-nodes on differentlevels.

ExampleYou create a connection object and premise. You replicate the nodes for the utilityinstallation. You maintain the sub-nodes of both utility installation nodes. The MDT thencreates two utility installations and two contracts.To carry out initial data creation in two separate steps, create two templates with categoryNEWCUST. The first template carries out the first stage of processing; the second partfinishes off processing at a later date.See below for more information on the individual nodes.

1.7.2 NEWCUSTThis MDT category is available as of Release 4.61. Unlike NEWCUSTPOD, you cannot useNEWCUST to create points of delivery and service at premise level. Points of delivery canonly be created at installation level using the POINT_OF_DELIVERY node. In comparison toNEWCUSTPOD, the following restrictions apply:

You cannot create a point of delivery without an installationYou cannot create a point of delivery and use it in more than oneinstallationYou cannot define services for the point of delivery

We therefore recommend that as of Release 4.63 you use the NEWCUSTPOD MDT categoryinstead of NEWCUST.

1.7.3 RATECHANGEThe RATECHANGE MDT category is suitable for changing rate data in an existinginstallation. It previously contained the two sub-nodes BCONTACT andINSTALLATION_CHANGE. You can use this MDT category to change the rate categoryand facts of an installation, for example. As of Release 4.64 you can also change the rate dataof an installation structure. To do this, see the notes mentioned in the descriptions ofDEVICE_BILL_INSTALL and REG_BILL_INSTALL.The INSTALLATION_CHANGE sub-node corresponds to the INSTALLATION MDTcategory, with which a utility installation is created. There are the following differences:


-24-

INSTALLATION_CHANGE does not have the attributes for divisionand premise, since these cannot be changed. You can useINSTALLATION_CHANGE to change the other, non-historicalattributes for an installation.

The hierarchy of INSTALLATION_CHANGE does not have theCONTRACT sub-node (create contract) andDEVICE_BILL_INSTALL (perform billing-related deviceinstallation in an installation). These categories can be used when anexisting installation is changed.

The hierarchy does contain the sub-nodes used for changed the historical installation data(INSTALLATION_HISTORY) and the sub-nodes for creating or changing installation facts.

1.7.4 BPARTNER and CONTRACT_ACCOUNTUsing an autonomous template category, you can create a business partner in the role of acontract partner and then make changes to it. Note that restrictions apply to the changes. Alsonote the roles of the following attributes:

BU_GROUP (grouping) controls the allocation of numbers. Alwaysuse a grouping that allocates internal numbers. MDT categories do notsupport external number allocation.

TYPE determines the business partner category. If you create abusiness partner in dialog using the Create business partnertransaction, you must enter the business partner category on the initialscreen. The category you choose determines the selection of fields thesystem displays on the next screen. In the MDT, you must maintainthe attributes that correspond to the business partner category youhave chosen. For more information, see the documentation in thetransaction.

With the NAME_FIRST and NAME_LAST attributes, you enter thefirst and last names of the business partner. These attributes aremandatory.

You can use the attribute VALDT to define that a change to a businesspartner should take effect at a later date (planned changes). If you donot use this attribute, the change becomes effective immediately. Ifyou enter a date that lies in the future, the change becomes effective asof this date. To do this, the change must be transferred to the masterdata using a special batch report. You cannot specify a date in thepast. The attribute VALDT is not included when you recreate abusiness partner.

Note


-25-

If you choose the Organization or Group categories for your business partnerthen do not use these attributes as name fields.Instead, use the following:

o In the case of Organization use the NAME_ORG1 to NAME_ORG4attributes

o ? In the case of Group use the NAME_GRP1 and NAME_GRP2attributes.

The XSEXM and XSEXF mandatory attributes determine the genderof the business partner. How you use these attributes depends on thebusiness partner category.o In the case of a person then mark one of the attributes XSEXM or

XSEXF. Leave the other attribute empty. As of SAP IS-U Release4.71, the attribute XSEXU is also available (gender of businesspartner is unknown).

o In the case of an organization or group, leave the aforementionedattributes empty. This means you must leave the value empty andnot change the evaluation category.

Templates that change the data of existing business partners can also useBPARTNER. To do this proceed as follows:

Enter the key of the existing business partner in the PARTNER.Do not change the BU_GROUP and TYPE attributes. For theseattributes, select the Allocate value in creation mode only field.

Use the Do not change evaluation category for all other fields whosevalues you do not want to change. Use the Parameter attribute for allattributes you want to change (such as MARST (marital status) orJOBGR (occupation).

For the BP_ADDRESS sub-node, choose one of the following options:o Do not activate BP_ADDRESS. The address data of the business

partner remains unchanged.o Activate BP_ADDRESS and maintain the ADDRNUMBER

attribute (address number). The address belonging to this addressnumber is changed.

o Activate BP_ADDRESS and leave the ADDRNUMBER attributeempty. The address is added the business partner’s existingaddresses. The other addresses remain unchanged.

NoteAs of SAP ECC Industry Extension Utilities, Waste & Recycling 6.0, or by implementing thecorrections for SAP note 878279, you can also create business partners with external numberassignment. Previously this was not supported in the master data generator. The following


-26-

rule applied: "If the partner number is empty, then the business partner is created again. Thenumber of the business partner is assigned internally. If a partner number is also replicated,then the master data generator tries to change this business partner. If this partner does notexist then the master data generator issues an error message."For technical reasons, the change mode cannot be supported in connection with the externalnumber assignment. If you want to change a certain business partner, then you must select theinternal number assignment.

- BP_PAYMENTUsing the optional BP_PAYMENT sub-node, you can maintain the bank details of a businesspartner. To create more than one set of bank details, replicate BP_PAYMENT. Youdifferentiate between the sets of bank details by the different bank details ID. You enter thesein the BKVID attribute.

BP_PAYMENT also allows you to change the bank details of existingbusiness partners.If you execute BP_PAYMENT with new bank details ID then a newset of bank details is created for that business partner.If you execute BP_PAYMENT with a business partner’s existing bankdetails ID then these details are changed.You cannot delete bank details.

- BP_CCARDUsing the optional BP_CCARD sub-node, you can maintain a business partner’s paymentcards. You do this in the same way as described above for BP_PAYMENT. Payment cardsare identified by means of the CCARD_ID attribute (payment card ID).

- BP_TAXNUM

Using the optional subnode BP_TAXNUM you can allocate a tax number to the businesspartner. The system stores the tax number with a tax number category. You can activate thenode several times and can maintain several tax numbers. However, only one tax number isallowed per tax number category. You can also allocate a new tax number to an existing taxnumber category.

- BP_IND_SECTORUsing the optional node BP_IND_SECTOR you can allocate one or more branches to abusiness partner from the Organization category. You cannot use this node for businesspartners from the categories Natural Person or Group.Note: Up to, and including IS-U Release 4.64 it was possible to use attribute IND-SECTORfrom the BPARTNER node to maintain the branch. For IS-U Release 4.71, the new nodeBP_IND_SECTOR replaced this attribute.

- BP_COPY_PREM_ADDR


-27-

Using the optional node BP_COPY_PREM_ADDR you can transfer the address of a premiseas a new address of a business partner.

- BP_ADDRESSUsing the BP_ADDRESS sub-node, you define the address data of a business partner. Whenyou create a new business partner, you can supply one or more addresses. If you create morethan one address then set the XDFADR attribute (selection is standard address).If you want to create a new address for the business partner, leave the value of theADDRNUMBER attribute (address number) empty. If you want to change an existingaddress for an existing business partner, you must transfer the address number in thisattribute.The address number is an internal field and is not displayed in dialog transactions. If you callthe MDG from one of your own applications and want to change addresses then you mustdetermine the address number beforehand. You can use the ISU_DB_PARTNER_SINGLEfunction module to determine address numbers. When you call this function module, set theX_XADDR_MULT indicator.If you try to create a business partner without an address, the system generates an errormessage. However, the cardinality of the sub-node allows you to deactivate the address node.This means you can define templates that change existing business partners without adding anew address.In the sub-nodes of BP_ADDRESS you can create and change telephone, fax and E-mail data.If you create the business partner with the NEWCUSTPOD template category, the businesspartner’s address may be changed when you perform the move-in. For more information, seeyour Customizing settings under SAP Utilities Customer Service Process ExecutionMove-In/Out Move-In Define Move-In Control Parameters on Document Level.

- BP_PHONEBP_PHONE is an optional sub-node of BP_ADDRESS. For each address, you can create oneor more telephone numbers. If you create more than one then set the FLGDEFAULT attributefor one of the numbers. This number is now noted as the default telephone number.If you want to create a new telephone number, set the Do not change evaluation category inthe CONSNUMBER attribute or use the initial value 000.

You can also change existing telephone numbers. To do this, you must have entered theaddress number in the ADDRNUMBER attribute in the BP_ADDRESS higher-level node. Inthe CONSNUMBER field of the BP_PHONE node you must specify the current number(001, 002) of the telephone number that you want to change. The following combinations ofaddress number and current telephone number are permitted:

BP_ADDRESSADDRNUMBER

BP_PHONECONSNUMBER

Effect

initial initial (000) The system creates a new address with anew telephone number

not initial initial The system adds a new telephone


-28-

number for an existing addressnot initial not initial (001,

002, ...)The system changes a telephone numberfor an existing address

initial not initial Not allowed !The same logic applies to the BP_FAX and BP_EMAIL

- BP_FAXBP_FAX is an optional sub-node of BP_ADDRESS. For each address, you can create one ormore fax numbers. If you create more than one fax number for an address then you must setthe FLGDEFAULT attribute in a sub-node. This number is now noted as the default faxnumber.

- BP_EMAILBP_EMAIL is an optional sub-node of BP_ADDRESS. For each address, you can create andchange one or more E-mail address.

1.7.4.1 CONTRACT_ACCOUNTWith CONTRACT_ACCOUNT you create one or more contract accounts for the businesspartner. You can also change existing contract accounts. The template category is notautonomous. If you want to create a contract account for an existing business partner, proceedas follows:

Activate the BPARTNER node. Set the evaluation category Do notchange for all attributes. Only select the evaluation category Parameterfor the PARTNER attribute.

Activate the CONTRACT_ACCOUNT sub-node of BPARTNERonly. The system automatically adopts the key of the business partnerfrom the business partner node.

You can use the VALDT attribute to execute planned changes to the contract account. Forfurther information see the explanations for attribute VALDT in the BPARTNER node.As of the release after SAP IS-U 4.72, and by making the corrections detailed in SAP note794688, you can also use the master data generator to enter values in the Move-In/OutDunning Procedure (MAHNVUMZ) field in the CONTRACT_ACCOUNT master datatemplate category.

1.7.5 DEVICE_INFO and REGISTER_INFOFor an overview of the hierarchy of DEVICE_INFO see the description of NEWCUSTPOD.You use the DEVICE_INFO MDT category to create device info records. The functioncorresponds to the Create device info record transaction, which can be found under UtilitiesIndustry Device Management Installation Device Info Record. Each time you executeDEVICE_INFO a new device info record is created. Existing device info records cannot bechanged.The template category DEVICE_INFO is autonomous. It is also part of the hierarchy of theNEWCUSTPOD template category. During initial data creation with NEWCUSTPOD, youcan create device info records and then install them (billing-related) in an installation.


-29-

The device info record functions were considerably enhanced for Release 4.64. TheDEVICE_INFO node was adjusted accordingly. The information below applies to Release4.64 only.

- DEVICE_INFO as of Release 4.64You use the KEYDATE and SPARTE attributes to define the date on which the device inforecord is created and with which division.The MATNR attribute defines with which device category the device info record is createdYou cannot use device categories in which the Device Info Record field contains the OnlyDevices Permitted entry.You use the SERNR attribute to define the device number with which the device info recordis created. If you maintain the SERNR attribute then the number is assigned externally. Notethat you cannot yet use a combination of SERNR and MATNR. In the device category, theDevice Info Record field contains Only Device Info Records Permitted; Multiple Ser. No. Poss.entry. You can also leave SERNR empty. If you do this, the numbers are assigned internally.However, you must have selected either the DevInfoRec.No.Allctn. (device info record:automatic number assignment permitted or DevInfo.No.AllMndtry (device info record:automatic number assignment mandatory) indicator beforehand. You can find these indicatorsin Customizing under SAP Utilities Device Management Installation Device Info RecordDefine System Parameters for Device Info Record.

CautionDEVICE_INFO does not export the new device numbers. If you define a parameter for theSERNR attribute, the new device number is not allocated to the parameter.The EQUNR attribute corresponds to the equipment number. Equipment numbers are alwaysassigned internally. They are also always unique, even if the device number is ambiguous. Ifyou use a parameter for the EQUINR attribute and a new device info record is created, thevalue of the new key is assigned to the parameter.As already mentioned, DEVICE_INFO only creates device info records and cannot changeexisting ones. However, some applications require that the master date template be run severaltimes. In the case of other objects, the object is changed if you transfer its key to the MDT. Ifyou call the BPARTNER node (business partner) with a value for the PARTNER key, thecorresponding business partner is changed. However, since DEVICE_INFO cannot carry outa device modification, the following logic is used instead:

If, when you call DEVICE_INFO, you allocate a value to the EQUINRattribute, a new device info record is not created. The system onlychecks whether a valid device info record exists for the transferredequipment number on the given key date (KEYDATE attribute).There is no further processing.

If you do not transfer a value in the EQUINR attribute, a new deviceinfo record is not generally created. Note however the followingexception:o You have maintained the SERNR attribute. A device info record

already exists for device number SERNR and device categoryMATNR on the key date (KEYDATE attribute).


-30-

o The device category belonging to the MATNR attribute does notpermit device info records with ambiguous device numbers.

If a new device info record is created, the new key is allocated to theEQUINR parameter. If, as described in the above exception, the device inforecord already exists, processing stops here. The value of the existing deviceinfo record is allocated to the parameter.

DEVICE_INFO is frequently used together with the DEVICE_BILL_INSTALL node. Youcan use DEVICE_INFO to create a device info record and then useDEVICE_BILL_INSTALL to install it (billing-related) in an installation. You should use theequipment number to link these two nodes. This has two advantages: the link functions whenyou use internal number assignment as well as in cases of ambiguous device numbers. It alsosupports a limited change mode.The interaction of DEVICE_INFO and DEVICE_BILL_INSTALL is illustrated in theexamples below.

Example 1: External Number AssignmentYou create an MDT with the NEWCUSTPOD category and maintain the following attributesin the DEVICE_INFO and DEVICE_BILL_INSTALL nodes:

Node Attribute

Data Source Value

DEVICE_INFO SERNR Parameter SERNR1DEVICE_INFO MATNR Constant 1000DEVICE_INFO EQUNR Parameter EQUNR1DEVICE_BILL_INSTALL

SERNR Do not change

DEVICE_BILL_INSTALL

MATNR Do not change

DEVICE_BILL_INSTALL

EQUNR Parameter EQUNR1

Operation a): You execute this MDT with the following values for the parameters:

Parameter ValueSERNR1 5432EQUNR1 (no value)

Result:In the DEVICE_INFO node, the MDT creates a device info recordwith device number 5432 and device category 1000. A newequipment number, 17400 is assigned. Prerequisite: The devicecategory either permits ambiguous number assignments or there is nodevice 5432 for this device category.

The EQUINR1 parameter passed the new equipment number to theDEVICE_BILL_INSTALL node. This node then installs (billing-related) the new device info record in the installation.


-31-

Note: you can choose a different type of value allocation, for example by parameter, for theMATNR attribute (device category). However, you must ensure that the device categoryalways matches the register data in the sub-node REGISTER_INFO or.REG_BILL_INSTALL.Operation b): You re-execute this MDT with the following values for the parameters:

Parameter ValueSERNR1EQUNR1 17400

Result:The DEVICE_INFO node recognizes that equipment number 17400already has device info record with device category 1000. It acceptsthis device info record and performs no further actions.

DEVICE_BILL_INSTALL recognizes that equipment 17400 hasalready been installed (billing-related) in the installation. The nodetherefore only allocates the rate data to the device info record.

Note: you could also have allocated the value 5432 to the SERNR1 parameter. This would nothave changed processing.Example 2: Internal Number AssignmentYou create an MDT with the NEWCUSTPOD category and maintain the following attributesin the DEVICE_INFO and DEVICE_BILL_INSTALL nodes:

Node Attribute

Data Source Value

DEVICE_INFO SERNR Do not changeDEVICE_INFO MATNR Constant 1000DEVICE_INFO EQUNR Parameter EQUNR

1DEVICE_BILL_INSTALL

SERNR Do not change

DEVICE_BILL_INSTALL

MATNR Do not change

DEVICE_BILL_INSTALL

EQUNR Parameter EQUNR1

Operation a):

Parameter ValueEQUNR1 (no value)

Result:As in example 1a, a new device info record with the equipmentnumber 17401 is created and installed. The device number is assignedinternally.

Operation b):


-32-

Parameter ValueEQUNR1 17401

Result:As in example 1, only the rate data is changed in existing installeddevice info records.

Example 3: Create Without Equipment NumberIn Release 4.63 the DEVICE_INFO node did not contain the EQUINR attribute. It was notnecessary either, since neither internal nor ambiguous number assignment was supported. Asbefore, you can create and install device info records. Example:

Node Attribute

Data Source Value

DEVICE_INFO SERNR Parameter SERNR1DEVICE_INFO MATNR Constant 1000DEVICE_INFO EQUNR Do not changeDEVICE_BILL_INSTALL

SERNR Parameter SERNR1

DEVICE_BILL_INSTALL

MATNR Constant 1000

DEVICE_BILL_INSTALL

EQUNR Do not change

Operation a): You execute this MDT with the following values for the parameters:

Parameter ValueSERNR1 5433

Result:In the DEVICE_INFO node, the MDT creates a device info recordwith device number 5433 and device category 1000.

The new device info record in installed in the installation (billing-related).

Operation b): You re-execute this MDT with the following values for the parameters:

Parameter ValueSERNR1 5433

Result:DEVICE_INFO recognizes that there is already a device info recordwith the number 5433 and device category 1000 and stops processing.In DEV_BILL_INSTALL, only the rate data is changed.

Important restrictions:MDTs with this structure only function if the numbers are externallyassigned. The template cannot be called if the device number


-33-

(SERNR) has not been maintained. In the same way, deviceinstallations with DEVICE_BILL_INSTALL are terminated if thedevice number is left empty.

MDTs with this structure cannot be used for device categories withambiguous device numbers. Device installations that usedDEVICE_BILL_INSTALL are terminated because no device can beuniquely identified.

We therefore recommend that you convert old MDTs that do not useequipment numbers, as described in example 1.

- DEVICE_INFO until IS-U Release 4.63In Releases 4.62 and 4.63, the following restrictions apply to the creation of device inforecords using the MDG:

Device info record numbers cannot be assigned internally. You musttherefore always enter the device number with which the device inforecord is to be created in the SERNR attribute.

Ambiguous device numbers are not permitted. In the SERNR andMATNR attributes, you must always specify a unique, as yet un-unused combination of device number and device category.

DEVICE_INFO does not have EQUNR (equipment number),SERVICE_PROV (service provider) and EGERR_INFO (informationfield) attributes.

DEVICE_INFO causes an error message if the device info recordbelonging to DSERNR and MATNR already exists. This was changedin Release 4.63 with SAP note 459827. If the device info recordalready exists, a warning is recorded in the log. Processing is notterminated.

The device info record is always created with the default register of theregister group. The DO_NOT_USE attribute cannot be used inREGISTER_INFO.

1.7.5.1 REGISTER_INFO as of IS-U-Release 4.64In the hierarchy, DEVICE_INFO is higher than the REGISTER_INFO master data templatecategory. If you do not activate the nodes for REGISTER_INFO in the MDT, the device inforecord is created as follows:

The register group for the device category (MATNR) is determined.In the register group, the system checks for registers in which the fieldPropose register during installation/replacement is selected.If this field is not selected in any of the registers, the device info recordis created with all the registers of the register group. If the field is(partially) selected, the device info record is created with the selected


-34-

registers. The attributes of the register group (register category. unit ofmeasurement for meter reading and so on) are adopted unchanged.

ExampleYou enter the device category 1000 in the MATNR attribute. Thecorresponding register group has two consumption registers. ThePropose register during installation/replacement field is selected in bothregisters. You do not activate the REGISTER_INFO node. When youexecute DEVICE_INFO, a new device info record with twoconsumption registers is created. The device info record’s characteristicsmatch those of the register group.

If required you can activate the REGISTER_INFO node of the MDT. This enables you tocreate the registers of the device category with characteristics that differ from those in theregister group.

ExampleYou enter the device category 1000 in DEVICE_INFO. In the secondregister, unlike the specifications in the register group, you want to havetwo decimal places. To do this proceed as follows:

You activate the REGISTER_INFO node.

In the ZWNUMMER attribute (register number) enter the constantvalue 002.

In the STANZNAC attribute (decimal places) enter the constantvalue 2.

In the other attributes, use the Do not change evaluation category.This ensures that the value from the register group is transferredunchanged.

If you want to change register 001 then you must replicate theREGISTER_INFO node.

NoteSeveral attributes can only be used depending on the division or registercategory. If in doubt, you can orient yourself on the Create device info recordtransaction.

REGISTER_INFO also enables you to override the register group with reference to thedefault registers. (Propose register during installation/replacement field). To do this, use theDO_NOT_USE attribute.

Example:You activate the DEVICE_INFO and enter device category 1000 forthe MATNR attribute. This device has a register group with four


-35-

registers. The first three registers are default registers; register 004 isnot.

You activate the REGISTER_INFO node with the following values:Node Attribute Data Source ValueREGISTER_INFO

ZWNUMMER Constant 002

REGISTER_INFO

DO_NOT_USE Do not change

REGISTER_INFO

STANZNAC Constant 3



REGISTER_INFO

DO_NOT_USE Constant X



REGISTER_INFO

DO_NOT_USE Constant

When you execute this MDT, you device info record is created with the followingcharacteristics:

Register 001 is created with the characteristics of the register group,since it the default register and you have not engaged the overridefunctions.Register 002 is also created. If you choose the Do not change option forthe DO_NOT_USE attribute, the register is only created if the registergroups stipulates that it is a default register. This is the case here. Theregister is created with 3 decimal places (STANZNAC attribute).Register 003 is not created, although the register group stipulates that itis a default register. This is because the DO_NOT_USE = ‘X’ attributeoverrides the register group.Register 004 is not created, although the register group stipulates that itis not a default register. This is because the DO_NOT_USE = ‘ ’attribute overrides the register group.

If you create a parameter for DO_NOT_USE, you can decide separately for each run whichregisters are created. If you install the device info record (billing-related) after creation, youmust of course ensure that there are REG_BILL_INSTALL nodes to match the existingregisters.


-36-

1.7.6 QPRICEUsing the QPRICE and QPRICE_HIST nodes you can create or change a price from the pricecategory Quantity-Based Price. You cannot delete prices details. Use the QPRICE node todefine the attributes of the price header. QPRICE_HIST is used to define the historical priceamounts. This MDG function is particularly useful for maintaining customer-specific pricesthat are only valid for a specific contract. See also the section Example: Individual Pricesand Installation Facts.You can also use the node from the QPRICE and QPRICE_HIST category to change existingprices. It is possible to make changes to a price header. However, the changes are generallymade to the price amounts. For example, it is possible to add a new price time slice to anexisting price.The attributes for the QPRICE node correspond to the fields in the price header. The attributesCUT_PAST, CUT_FUTURE and MNGBASIS_CONVERT are exceptions, which control theprocessing of historical price data.

1.7.7. QPRICE_HISTThe QPRICE_HIST node has the following attributes:

The mandatory attribute ABDATUM determines the date from which theprice is valid.The BISDATUM attribute determines the end of the validity period forthe price. BISDATUM is optional. If you do not maintain the attribute,the system sets the value to 12.31.9999.The VONZONE attribute (from-block for the price) is important forprices with the Block Price or Scale Price price type. Leave this attributeempty for normal prices. The system then internally sets the value to “0”.There is no specific attribute for the to-zone of the price. The to-zone isset internally, and is dependent upon the pre-defined from-zones.The optional attribute MNGBASIS enables you to enter a quantity base,to which the price refers. If you do not maintain the attribute, the systemsets the value to “1”.Use the attribute PREISBTR to maintain the price amount. Use theattribute TWAERS to transfer the corresponding currency. You cancreate price amounts in different currencies for the same price header.

Example: You use the master data generator to create a price withcurrency 1. You then recall the master data generator to change thisprice. You enter currency 2 in the TWAERS attribute. As a result, theprice now has two currencies. The price amounts for the first currencyare not changed when you call the master data generator for the secondtime.

NoteFor the price history attributes, Do Not Change has the same meaning as DataSource = Constant and Value = Initial Value. You can also create a master data


-37-

template that only changes the price’s quantity base, but uses Do Not Changeto leave the price amount unchanged.

The following rules apply when using QPRICE_HIST to handle periods:You can activate more than one node from the price history, andspecify different values for the from-date. In the following, theearliest from-date is called the Start Date.

The node with the most recent from-date uses the to-date to determinethe End Date. If you do not maintain the optional to-date, then the enddate is set to 12.31.9999. If the to-date has a final value, this value isadopted as the end date. If several nodes have different from-dates,only the to-date from the most recent time slice acts as the end date.The other to-dates are ignored.

Gaps in the time definition are not permitted. This corresponds to theonline transaction. If the master data template contains more than onetime slice, the old time slice is always extended to the from-date forthe next time slice. For this reason, only the to-date from the mostrecent time slice is important.

All the properties of the price before the start date remain unchanged.Old price time slices remain as they are, or are prorated to the startdate.

All the properties of the price between the start and end date aredetermined using the value from the master data generator.

What happens to the price time slices after the end date depends uponthe end date and the value of the attribute CUT_FUTURE Limit Pricein Future from the QPRICE node:a) If the end date has the value 12.31.9999 (for example, no to-date isspecified), then the master data generator determines the values forthe whole time stream from the start date. The value of the attributeLimit Price in Future is irrelevant.b) If the end date has a value lower than 12.31.9999 and the LimitPrice in Future attribute has the initial value, the price properties arenot changed after the end date. Possible existing time slices are, ifnecessary, prorated to the end date.c) As b), but Limit Price in Future = ‘X’: Possible existing time slicesare deleted after the end date. The price is limited to the end date. Thisapplies for all currencies.

If time slice for the price exist before the start date, then the followingprocess takes place, depending on the CUT_PAST attribute LimitPrice in Past:Limit Price in Past = ‘X’: The price history before the start date iscompletely deleted. This applies for all currencies.Limit Price in Past = ‘SPACE’: The price history before the start dateremains unchanged.


-38-

You must also note the following rule for block and scale prices:For a block price, the user must activate the price history node for allblocks. You cannot change just one of a number of blocks.

Example 1 For Historical Price ChangesFor the purpose of this example, the price with the key 1000 has the followinghistorical price amounts:

From-date To-date Priceamount

01.01.2003 31.03.2003 1,4001.04.2003 31.12.9999 1,50

You create a master data template, activate QPRICE and replicate the QPRICE_HIST node.You run the master data generator with the following attributes, to change the price 1000:

Node Attribute ValueQPRICE PREIS (price key) 1000QPRICE CUT_PAST -QPRICE CUT_FUTURE -QPRICE_HIST (first node) AB (from-date) 01.06.2003QPRICE_HIST (first node) BIS (to-date) -QPRICE_HIST (first node) PREISBTR (price

amount)1.60

QPRICE_HIST (second node) AB (from-date) 01.08.2003QPRICE_HIST (second node) BIS (to-date) -QPRICE_HIST (second node) PREISBTR (price

amount)1.70

After you have run the master data generator, the price has the following historical priceamounts:


01.01.2003 31.03.2003 1.4001.04.2004 31.05.2003 1.5001.06.2003 31.07.2003 1.6001.08.2003 31.12.9999 1.70

Graphic:


-39-

1.60MDG

1.70

1.40Price before

01.01.2003

1.50

01.04.2003

Price after 1.701.40 1.50 1.60

01.06.2003

01.08.2003

Note:The time slices of the existing price are automatically prorated.You must not set the to-date in the master data template.

Example 2 For Historical Price ChangesFor the purposes of this example, the price with the key 1000 has the sameconditions as in example 1. You change this price again, using the master datagenerator, then run a template with the following values:

Node Attribute ValueQPRICE PREIS (price key) 1000QPRICE CUT_PAST X-QPRICE CUT_FUTURE XQPRICE_HIST (first node) AB (from-date) 01.06.2003QPRICE_HIST (first node) BIS (to-date) -QPRICE_HIST (first node) PREISBTR (price

amount)1.60

QPRICE_HIST (second node) AB (from-date) 01.08.2003QPRICE_HIST (second node) BIS (to-date) 30.09.2003QPRICE_HIST (second node) PREISBTR (price

amount)1.70

After you have run the master data generator, the price has the following historicalprice amounts:


-40-


01.06.2003 31.07.2003 1.6001.08.2003 30.09.2003 1.70

Graphic:

1.60MDG

1.70

1.40Price before

01.01.2003

1.50

01.04.2003

Price after 1.701.60

01.06.2003

01.08.2003 30.09.2003

Note:The attributes CUT_PAST and CUT_FUTURE ensure that the existinghistorical price data is not prorated, but is deleted. The system onlysaves the periods that are covered by the master data generator.

The to-date of the node with the old from-date is irrelevant and mustno longer be completed.

Meaning of the Quantity BaseThe quantity base, to which the price amount refers, is located in the MNGBASIS attribute ofthe node QPRICE_HIST. The MNGBASIS attribute is optional. If you do not use theattribute, the price is created with the quantity base 1.In addition, the QPRICE node contains the MNGBASIS_CONVERT attribute. When you usethis attribute you activate a conversion of the price amount to this quantity base, in the masterdata generator. The master data generator converts the price amount (PREISBTR attribute inQPRICE_HIST node) from the quantity base MNGBASIS of the QPRICE_HIST node to thequantity base MNGBASIS_CONVERT of the QPRICE node.

Example: You run the master data generator to create a price. You complete the attributesas follows:


-41-

Node category Attribute ValueQPRICE MNGBASIS_CONVE

RT1

QPRICE_HIST MNGBASIS 1000QPRICE_HIST PREISBTR 143.25

Result: The system creates the price with the quantity base 1 and the price amount 0.14325.Background: This technology allows you to create price amounts with many decimal places(here 0.14325 has 5), although a value with less decimal places was originally transferred tothe attribute for the price amount (here 143.25 has only 2 decimal places). This is particularlyuseful in connection with the CRM integration. This is because, in CRM, only as manydecimal places are available for prices as are available for amounts (as a rule, only 2 decimalplaces).

NoteImportant restrictions: If you use attribute MNGBASIS_CONVERT youcan only use the values 1, 10, 100, 1000, 10000, and so on, for thisattribute and the MNGBASIS attribute. This restriction ensures that onlydecimal places are moved during the conversion. A different conversion(such as quantity base 3 to quantity base 1) could lead to roundingerrors.

CRM PricesThe following aspects are important for IS-U/CRM integration:

As of release 4.71, the price header contains the field Price Origin. Forprices that were generated by a CRM master data template, this fieldcontains the value Price Created in CRM. You can no longer use theonline transaction in SAP IS-U to manually change these prices. Forprices created using the online transaction in SAP IS-U or a templatefrom the NEWCUSTPOD category, the field contains the value PriceCreated in IS-U.

For CRM template categories, the parameter names of the nodes fromthe QPRICE_HIST category are automatically generated. Theparameter names are generated internally.

LPRICEUsing the TPRICE and TPRICE_HIST nodes you can create or change a price from the pricecategory Flat Rate. The function corresponds to the quantity-dependent prices.

TPRICEUsing the TPRICE and TPRICE_HIST nodes you can create or change a price from the pricecategory Time-Dependent Price. The function corresponds to the quantity-dependent prices.


-42-

1.7.7 CONNOBJFor an overview of the hierarchy of CONNOBJ, see the description of NEWCUSTPOD.You can use CONNOBJ to create or change a connection object. The address(CONNOBJ_ADDR sub-node) is mandatory.The DEVICE_LOCATION sub-node enables you to create a device location. The devicelocation is automatically allocated to the connection object.Using the optional PREMISE sub-node, you can create one or more premises for yourconnection object. The premises are automatically allocated to the connection object. You canalso create new premises for existing connection objects.

1.7.8 DEVICE_LOCATIONFor an overview of the hierarchy of DEVICE_LOCATION , see the description ofNEWCUSTPOD.You can use the autonomous MDT category DEVICE_LOCATION to create or change adevice location. DEVICE_LOCATION is part of the hierarchy of CONNOBJ (connectionobject) and thereby NEWCUSTPOD (initial data creation).You use the HAUS attribute (connection object) to allocate the device location to aconnection object. If you want to change an existing device location, this attribute ismandatory. In the case of templates with the category CONNOBJ or NEWCUSTPOD the keyof the higher-level connection object generated in the hierarchy is automatically used. Youcan also use DEVICE_LOCATION to allocate more than one device location to a connectionobject. You cannot explicitly allocate a device location to a premise.

1.7.9.1 DEVICE_TECH_INSTALL and REG_TECH_INSTALLDEVICE_LOCATION contains the sub-category DEVICE_TECH_INSTALL. The MDTcategory enables you to technically install one or more devices in the device location.DEVICE_TECH_INSTALL does not have a change mode.DEVICE_TECH_INSTALL contains attributes at device level. The following attributes aremandatory:

With SERNR (device number) and MATNR (device category), youdefine which device you want to install. Alternatively, you can use theEQUINR attributes and specify the equipment number of the device.If you do this, you must set the MATNR and SERNR attributes totheir initial values or use the Do not change evaluation category.

The higher-level DEVICE_LOCATION node automatically transfersthe DEVLOC attribute (device location).

HAUS (connection object) is also automatically assigned a value,unless you use DEVICE_LOCATION autonomously.

NoteYou can install a transformer in the device location. You can then installa second device and allocate it to the transformer. The same applies topressure regulators and audio-frequency ripple control receivers(ARCRs). You use the equipment number to allocate transformers,


-43-

pressure regulators or ARCRs to a device. Use one of the followingattributes:

WANDNRE: Transformer equipment numberDRUCKNRE: Pressure regulator equipment numberTRENRE: ARCR equipment number

You allocate device installation data at register level using the sub-nodes with theREG_TECH_INSTALL category. You must activate this node for each register of thespecified device- more than once if necessary. The following attributes are mandatory:

With ZWNUMMERE (register number) you specify the register of thedevice to which the data refers.With PERVERBR you maintain the period consumption of theregister.

With ZWSTANDCE you enter the meter reading at device installation.

NoteSome attributes of DEVICE_TECH_INSTALL and REG_TECH_INSTALLare dependent on the division or register category. If in doubt you can orientyourself on the Technical Installation transaction on the SAP Easy Accessmenu under Utilities Industry Device Management Installation.

1.7.9.2 SERV_FREQ_SERV_LOCDEVICE_LOCATION contains the sub-category SERV_FREQ_SERV_LOC. You can usethis MDT category to allocate a service frequency to a container on the container location (inthe Waste Management component, the device location is called container location and thedevice is called container).In the hierarchy, SERV_FREQ_SERV_LOC is underneath the DEVICE_LOCATION node.The service frequency therefore always refers to the container location that was created orchanged using DEVICE_LOCATION. The DEVLOC node (device location- in this casecontainer location), is always transferred by the automatic key assignment functionality.SERV_FREQ_SERV_LOC is not underneath DEVICE_TECH_INSTALL. This means thatyou can activate SERV_FREQ_SERV_LOC when DEVICE_TECH_INSTALL is inactive.You can activate the SERV_FREQ_SERV_LOC node more than once. If you do so, you mustuse a different parameter in the SERNR attribute (serial numberin this case containernumber)/equipment number for each container.

Example 1You activate the DEVICE_LOCATION node and used the DEVLOCparameter for the DEVLOC attribute.You activate the DEVICE_TECH_INSTALL twice and use theparameter names SERNR1 and SERNR2 for the SERNR attribute.


-44-

You activate the SERV_FREQ_SERV_LOC node twice and use theSERNR1 and SERNR2 parameter names for the SERNR attribute.Automatic key assignment is used for the DEVLOC attribute.You execute the MDT and transfer container numbers for the SERNR1and SERNR2 parameters. Leave the DEVLOC parameter empty.Result: a new container location is created. The two containers aretechnically installed. A service frequency is installed to each container.

Example 2You activate the DEVICE_LOCATION node and used the DEVLOCparameter for the DEVLOC attribute.You do not activate the DEVICE_TECH_INSTALL node.You activate the SERV_FREQ_SERV_LOC node and use the parametername SERNR for the SERNR attribute. Automatic key assignment isused for the DEVLOC attribute.You execute the MDT and transfer the key of an existing containerlocation for the DEVLOC parameter. In the SERNR parameter, youtransfer the key of a container that is already technically installed in thecontainer location.Result: The installed containers are allocated to a service frequency.

NoteYou cannot use the MDG to change or chronologically restrict existingservice frequencies. You can only execute SERV_FREQ_SERV_LOCfor containers to which a service frequency has not yet been allocated.SERV_FREQ_SERV_LOC can only be used for containers that areinstalled in the higher-level container locations.

You can use the ENQUNR attribute (equipment number of the container) as an alternative tothe MATNR (container category) and SERNR (container number) attributes.In the optional AB attribute, you can enter the date as of which the service frequency is to beallocated to the container. If you do not enter a value the date on which the container wastechnically installed on the container location is copied.The STARTTIME, STOPTIME and TIMEFRAME attributes can only be used together. Thismeans, if one of these attributes is allocated a value then so must the other two. This alsoapplies to the SEASON_FROM and SEASON_TO attributes.Depending on whether you create a weekly, monthly, daily or one-off service, several fieldsare mandatory. See the table below for more information (note, the entry X means theattribute has a value).

Attribute Weekly Monthly

Daily One-Off

WEEKLY XEWEEKDAY X X


-45-

MONTH_COUNT

X

MONTHLY XDAY_TYPE X X

1.7.10 POD_STAND_ALONEYou can use POD_STAND_ALONE to maintain points of delivery at premise level. You usethe INT_UI attribute to define whether you create or change a point of delivery.

If you allocate a value to INT_UI, the corresponding point of delivery ischanged.If you leave INT_UI initial, a new point of delivery is created and a newpoint of delivery key determined This new key can be transferred by keyreference via the INT_UI attribute to the lower-levelPOINT_OF_DELIVERY node. You use POINT_OF_DELIVERY toallocate the point of delivery to a utility installation. If a premise hasseveral nodes from the POINT_OF_DELIVERY category, the new pointof delivery is allocated to several installations.

You can use the NBSERVICEPROVRELMETH and NBSERVICEOPAREA sub-nodes tocreate services for the point of delivery. You require this functionality if you are using theIntercompany Data Exchange component (IDE). For a description of these MDT categories,see the Intercompany Data Exchange cookbook in the service market place. Choose Enternow and log on with your user and password. You then choose Solution Details IndustrySolutions mySAP Utilities mySAP Utilities in Detail Key Functional AreasIntercompany Data Exchange Literature Cookbook Intercompany Data Exchange 4.63.

1.7.11 PREMISEFor an overview of the hierarchy of PREMISE, see the description of NEWCUSTPOD.Generally, the PREMISE MDT category is used as a sub-node of NEWCUSTPOD (initialdata creation) or CONNOBJ (connection object). However, you can also use PREMISEindependently to create or change a premise.You can use the INSTALLATION sub-node to create one or more utility installations, orchange them, albeit with restrictions. You can use the CONTRACT sub-node to create a newcontract for each utility installation. You can use the CONTRACT sub-node to define thecharacteristics of the contract. To create a new contract, leave the contract key empty(attribute (VERTRAG) in the CONTRACT node. The move-in is not created until later, withthe MOVE_IN sub-node. This results in the following rules:

If you activate one or more CONTRACT sub-nodes, to createcontracts, you must also activate the MOVE_IN (move-in) node.

If there is no active CONTRACT sub-node then MOVE_INcannot be activated either.

You can also use the CONTRACT node to change an existing contract. To do this, you mustassign a contract key to the VERTRAG attribute. The existing contract is changed directly inthe CONTRACT node. The MOVE_IN node ignores contracts to be changed.


-46-

The INSTALLATION node can be activated repeatedly. You can therefore, for example,simultaneously create an electricity contract and a gas contract for the same premise (thecorresponding installations can either be existing or new). In this case, the MOVE_IN sub-node, which can occur only once, creates a move-in document that contains both contracts.

1.7.11.1 MOVE_INIf you execute MOVE_IN as a sub-node of NEWCUSTPOD, the value of the contractaccount key from the CONTRACT_ACCOUNT sub-node is automatically allocated to theVKONT attribute. Otherwise you must transfer the contract account, for example as aparameter.You use the EINZDAT attribute (move-in date) to define the move-in date of the contracts tothe premise.The EINZBELEG (as of IS-U Releases 4.64+, 4.71+, 4.72+) do not play a role in theexecution of the MOVE_IN node. You cannot enter the key from a move-in document in thisattribute in order to change an existing move-in document. The attribute only enables you toaccess the move-in document after you have run the master data template. To do this, youmust select Parameter in the template for the attribute. After you have executed the functionmodule ISU_PRODUCT_IMPLEMENT you can then get the move-in document numberfrom the export table XY_NEW_KEYS_TAB.In move-in Customizing you can determine whether the premise address is to become the newstandard address for the business partner. In Customizing for SAP Utilities, select CustomerService Process Execution Move-In/Out Move-In Define Move-In ControlParameters at Document Level.As of IS-U Release 4.72, you can override these settings with the attributeCOPY_PREMISE_ADDR when executing the node.

If you set the COPY_PREMISE_ADDR attribute to the value ‘0’, thepremise address is not adopted as the new standard address for thebusiness partner, regardless of the settings in Customizing.If you set the COPY_PREMISE_ADDR attribute to the value ‘1’, thepremise address is adopted as the new standard address for the businesspartner, regardless of the settings in Customizing.If you do not activate the COPY_PREMISE_ADDR attribute (Do NotChange), or set it to the value ‘ ‘, the move-in observes the specificationsin Customizing.

In the aforementioned Customizing table you can also define whether a welcome letter is tobe automatically generated. As of IS-U Release 4.72, you can override these settings with theattribute CREATE_WELC_LETTER when executing the node.

If you set the CREATE_WELC_LETTER to the value ‘0’, no welcomeletter is generated.If you set the CREATE_WELC_LETTER to the value ‘1’, a welcomeletter is generated.


-47-

If you do not activate the CREATE_WELC_LETTER attribute (Do NotChange), or set it to the value ‘ ‘, the move-in observes the specificationsin Customizing.

In the implementation guide for SAP Utilities you can define whether the system is togenerate a customer contact during move-in. You do this under Customer Service ProcessExecution Move-In/Out Define System Parameters for Move-In and Move-Out. If youselect the settings that mean that the system creates a customer contact, you can use thefollowing attributes from the sub-node MOVE_IN_BCONTACT.

CTYPE Contact typeALTPARTNER Contact partnerCTDATE DateCTTIME time.

If the Customizing settings mean that no customer contact is to be created during move-in,these attributes are irrelevant.You can use the TDLINE (text line) attribute to enter a text line as a notice for the move-indocument.In dialog, you create a move-in using transaction EC50E. On the initial screen you can finddetailed information on the move-in functionality in the menu under Help Applicationhelp. This documentation is also to a great extent applicable to automatic processing by theMDG. Familiarize yourself with this information before you begin.Example: during a move-in into an installation with metering devices, meter reading resultsmust be entered. You can adopt existing meter reading results as the meter reading results atmove-in. The details are controlled by the Customizing settings. Also, read the section onmeter reading data in the application help.

- MOVE_IN_BBPYou can use the MOVE_IN_BBP sub-node to create budget billing plans in the move-in. Thefollowing prerequisites must have been met:

In the contract account for which the move-in is to be performed, theBudget Billing Procedure indicator must contain the value 1 StatisticalProcedure or 2 Debit Entry Procedure. Otherwise a budget billing plan isnot created. If you use the MDG to create the contract account (MDTcategory CONTRACT_ACCOUNT), you must enter the value 1 or 2in the KZABSVER attribute.

If the budget billing cycle of the contract, or the portion belonging tothe installation has the value 00, a budget billing plan is not created.

You can, as already mentioned, create more than one installation and contract for eachpremise. For this reason, the MOVE_IN_BBP sub-node can be activated more than once.Activate this sub-node for each installation, for whose contract you want to create a budgetbilling plan. Use the attributes as follows:

In the ANLAGE attribute (installation), you must specify the key ofthe installation for whose contract you want to create a budget billing


-48-

plan. Since the MOVE_IN_BBP node is not a sub-node ofINSTALLATION, you cannot use the Key Reference evaluationcategory. Instead, in the case of the INSTALLATION andMOVE_IN_BBP nodes, you respectively use the same parameter forthe ANLAGE attribute.

You can use the BBP_FORCE indicator to force the creation of abudget billing plan, even if there are no open due dates before the nextperiodic billing date. The budget billing plan is then created in thesubsequent period. If you do not set BBP_FORCE, and there are noopen due dates, a budget billing plan is not created. Processingcontinues and there are no error messages.

You can use the ABSBETRW attribute to specify a budget billingamount. This amount is divided among the due dates according to therules of the budget billing plan. If you do not specify an amount, thebudget billing amount is calculated by the billing simulation.

If you enter a value in the ABSBETRW attribute (budget billingamount in transaction currency), you must also specify thecorresponding currency in the WAERS attribute.

If you perform a move-in with more than one contract, the Invoicecontracts together control decides whether each contract has its ownbudget billing amount. A budget billing plan for all the contracts iscreated for contracts in which the control (see the GEMFAKTattribute in the CONTRACT node) contains the value 1 Contract mustbe invoiced jointly with other contracts

Contracts in which the value 2 Contract can be invoiced jointly with othercontracts or 3 Contract must not be invoiced with other contracts is used,are always given their own budget billing plan.

If the budget billing plan cannot be created because, for example, the meter reading results atmove-in are missing, the MDG reacts are follows:

Processing continues. The move-in document is created.A warning is recorded in the log.The BudgetBillingPlansFailed event is triggered for the MOVEINDOCBOR object. The affected contracts are written to the event containeras a table (to be precise, to the Contracts container element).

If an error occurs, you can use the Change move-in transaction (EC51E) to create the budgetbilling plan. If an external budget billing plan was specified via the ABSBETRW attribute,this amount is proposed.

- MOVE_IN_MRMeter reading results at move-in must be created for billing-relevant registers that areinstalled in the installation. There are various ways of doing this:


-49-

You execute the move-in with the MDG, without entering the meterreading results. You then use the Change move-in transaction(EC51E) to manually enter the meter reading results at move-in.

In the IMG, go to SAP Utilities Device Management Meter ReadingBasic Settings Define Control Parameters for Meter Reading DataProcessing and maintain an interval that defines the default value forthe move-in. Based on this setting, the MDG checks whether theinterval contains suitable meter reading results. If so, the results areautomatically adopted as the meter reading results at move-in. Formore information see the Create Move-In transaction (EC50E) in themenu under Help Application help Move-in Meter reading data.

Third option: you activate the MOVE_IN_MR node and use it to entera meter reading result at move-in.

Use the attributes of MOVE_IN_MR as follows:With EQUNR (equipment number) and ZWNUMMER (registernumber), you define the register for which you want to enter a meterreading result. You can use a value for the SERNR (device number)and MATNR (device category) attributes as an alternative toEQUINR. Note however, that you cannot use this alternative if thedevice info record has an ambiguous device number. We thereforerecommend that you use EQUINR whenever possible.

In the ZWSTAND attribute, you specify the meter reading.The other attributes are optional.

- MOVE_IN_SECAs of the release after SAP IS-U 4.72, you can use the MOVE_IN_SEC subnode in the move-in to create cash security deposits for an installation/installations. You must observe thefollowing general conditions when processing this subnode:

In the ANLAGE attribute, you must specify the key of the installation,for the contract of which you want to create a cash security deposit.Either populate the Reason for Requesting Security Deposit(SEC_REASON), Reason for Requesting Noncash Security Deposit(SEC_TOT_AMOUNT) and Transaction Currency (WAERS) attributecombination, or just the Reason for Exemption from Security Deposit(SECWAIVERAS) attribute.

As mentioned previously, you can create several installations and contracts for each premise(apart from for those with the CRMNEWCONTRACT master data template category). Forthis reason, you can activate the MOVE_IN_SEC subnode more than once. Activate the nodefor each installation, for which you wish to create a cash security deposit for their contract.Use the attributes as follows:


-50-

In the ANLAGE attribute, you must specify the key of theinstallations, for which you wish to create a cash security deposit fortheir contract. Because the MOVE_IN_SEC subnode is not a subnodefrom INSTALLATION, you cannot use the Key Reference evaluationcategory. Instead of this, use the same parameter in theINSTALLATION and MOVE_IN_SEC nodes for the ANLAGEattribute.You can use the SEC_TOT_AMOUNT to determine the requestedsecurity deposit amount.If you have filled the SEC_TOT_AMOUNT and WAERS attributes,you must specify a reason for requesting a security deposit in theSEC_REASON attribute. You can only create a security deposit if youhave filled all these three attributes.If the business partner is exempt from paying a security deposit, youmust specify a reason for this exemption in the SECWAIVEREASattribute.It is not advisable to fill both the SEC_TOT_AMOUNT and WAERSattributes, and then to populate the SECWAIVEREAS attribute.

If you cannot create the cash security, the master data generator reacts as follows:The processing is continued. The move-in document is created.A currency is written in the log.

The SecurityDepositFailed event is triggered for the MOVEINDOC BOR object.


-51-

1.7.11.2 INSTALLATIONYou can use the INSTALLATION MDT category to create or change a utility installation.This MDT category is generally used as a sub-node of NECUSTPOD. However, you can alsouse INSTALLATION as an autonomous MDT category.

NoteYou can create autonomous MDTs with the INSTALLATION category.However, if you do so, you cannot activate the node for the CONTRACT sub-category. For an explanation, see the PREMISE master data template category.

- INSTALLATION_HISTORYThe mandatory INSTALLATION_HISTORY sub-node contains the historical data of theinstallation. When a new installation is created, the AB attribute (date, from which a timeslice is valid) defines the start of the installation. When an existing installation is changed,you use AB to define the start of a new time slice. Note that a time slice that has already beenbilled cannot be changed.

Normal Installation FactsYou generate or change normal installation facts (installation facts that are not referencevalues) using the sub-nodes named after the operand categoriesINST_FACTS_ADISCABS,...,INST_FACTS_USERDEF.You use the AB and BIS (date, to which a time slice is valid) attributes to define the time slicefor which an installation fact is valid. If you want the fact to be permanently valid, set the BISattribute to 31.12.9999. As of IS-U Release 4.71, an empty to-date is automatically interpretedas 12.31.9999. This is also the case in Release 4.6x if you import the correction for SAP note581446.You can activate the sub-nodes of the facts repeatedly. This enables you to:

Create several facts, each with different operands but the same operandcategory

Create more than one time slice for one operandMaintain various seasonal values for one operand (if you do not want aseasonal reference, set the either the initial value or the Do not changeevaluation category in the SAISON attribute)

If you change the facts of an existing installation, the existing facts may be prorated.

ExampleThe utility installation contains a fact for the FACTOR1 operandwithout a seasonal reference for the period 1.1.2000 to 31.12.9999 anda fact for the FACTOR2 operand.

In the template, activate the INST_FACTS_FACTOR node with theFACTOR1 operand without a seasonal reference with the time slice1.7.2000 to 31.12.9999.


-52-

After you have executed the template, the installation contains twotime slices for the FACTOR1 operand: 1.1.2000 to 30.6.2000 with theold value and 1.7.2000 to 31.12.9999 with the new value from theMDT. The fact for the FACTOR2 operand remains unchanged.

NoteYou cannot use the MDG to delete or chronologically restrict an installationfact.

As of the release after SAP IS-U 4.72, and by implementing the correctionfrom the 787361 SAP note, you can specify the value “0” for the followinginstallation facts:

Fact INST_FACTS_AMOUNT Attribute BETRAGFact INST_FACTS_DEMAND Attributes LMENGE &LMENGE2Fact INST_FACTS_FACTOR Attribute FACTORFact INST_FACTS_INTEGER Attribute INTEGER4Fact INST_FACTS_QUANT Attributes MENGE & MENGE2

Nodes for price operands also have the optional sub-nodes LPRICE_INST_ASSIGN,QPRICE_INST_ASSIGN and TPRICE_INST_ASSIGN. These nodes define an installationreference. This means that the key for the utility installation (attribute ANLAGE in thehigher-level node INSTALLATION) is entered in the price header of the price used in the fact(attribute PREIS in higher-level node). This installation reference means that the price canonly be used in the installation facts of the affected installation. In this way you can ensurethat a customer-specific price is not inadvertently used for the wrong contract. You can nolonger delete or change the installation reference for a price. In connection to installation factsthat are maintained using the master data generator, two indicators, which you can maintainwhen defining the operand, are very important.

Product-Related OperandContract-Related Operand

If you use an operand in an installation fact, in which Product-Related Operand is selected,the following applies:

You can no longer change this fact in the dialogFor a move-out, the fact is automatically completed for the move-outdate.

In the integration solution between SAP CRM and SAP IS-U you must check, for each factnode, whether the indicator is set for the corresponding operand. It should only be possible, inthe dialog, to change those facts whose values in IS-U are independent of the CRM system.If you use an operand with the indicator Contract-Related Operand in an installation fact, thisfact is automatically deactivated for move-out. For the meaning during move-in, see the


-53-

online documentation for the indicator. You should use this indicator for all facts that refer toa particular contract, such as individual prices.

- Example: Individual Prices and Installation FactsTo use the master data generator to create a customer-specific price, proceed as follows:

Activate the QPRICE and QPRICE_HIST nodes. Use the data sourcetype Parameter for the PREIS (price key) attribute.Activate the INSTALLATION node (create utility installation). There,activate the INST_FACTS_QPRICE sub-node, in order to generate aninstallation fact with the operand category QPRICE. For the PREISattribute, use the same parameter name as in the QPRICE node. Usean operand in which the indicator Contract-Related Operand isselected.

Activate the QPRICE_INST_ASSIGN sub-node.

When you run the template, the master data generator creates the following objects:It generates a new quantity-based price. An internal numberassignment is active for the price key.

The system generates the utility installation with an installation fact.The price operand refers to the price key of the new price. This priceis used for billing the current contract. You must, however, use a priceoperand from the billing scheme. The Contract-Relevant Operandindicator ensures that the installation fact is used for a move-out.

The key for the new utility installation is entered in the price header.This ensures that you can only use the price in the installation facts ofthis installation.

The changes to customer-specific prices are a little confusing. This is because there is aninterplay here between the time slices for utility installations, installation facts, contracts andprices. The following example should make things easier to understand.For the purposes of this example we are assuming that you want to use a template to createcustomer-specific prices, and to allocate these prices to a particular contract. Amongst others,you activate the following nodes and parameters:

Node category Attribute Parameter nameQPRICE PREIS (price key) PRICEKEYQPRICE_HIST ABDATUM (from-date of

price)FROMDATE_PRICE

QPRICE_HIST PREISBTR (priceamount)

AMOUNT_PRICE

INSTALLATION_HISTORY

AB (from-date ofinstallation)

FROMDATE_INST

INST_FACTS_QPRICE AB (from-date of fact) FROMDATE_FACTS

INST_FACTS_QPRICE PREIS (price key) PRICEKEY


-54-

MOVE_IN EINZDAT (move-in date) MOVE_IN_DATE1st Step: Run master data generator

Run the master data generator and use the following values for the parameters:

Node category Parameter name ValueQPRICE PRICEKEY -QPRICE_HIST FROMDATE_PRIC

E01.01.2003

QPRICE_HIST AMOUNT_PRICE 0.20INSTALLATION_HISTORY

FROMDATE_INST 01.01.2003

INST_FACTS_QPRICE FROMDATE_FACTS

01.01.2003

INST_FACTS_QPRICE PRICEKEY -MOVE_IN MOVE_IN_DATE 01.01.2003

Result:

Installation 2000Installation

Price key = 1000Fact

Price key = 1000, Price amount = 0.20Quantity price

3000Contract

01.01.2003

The system created a new price and internally issued the price key1000.

The system creates a new utility installation with the installation key2000. The price fact contains the price key 1000.

A new contract with the key 3000 is created. Price amount 0.20 is usedwhen billing this contract.


-55-

2nd StepRun the master data generator and use the following values for the parameters:

Node category Parameter name ValueQPRICE PRICEKEY 1000QPRICE_HIST FROMDATE_PRIC

E01.04.2003

QPRICE_HIST AMOUNT_PRICE 0,21INSTALLATION_HISTORY



01.04.2003

INST_FACTS_QPRICE PRICEKEY 1000MOVE_IN MOVE_IN_DATE -

Result:


1000Fact

1000/0.21Quantity price

3000Contract

04.01.2003

1000/0.20

1000

The price amount of price 1000 is changed on 04.01.2003.The price key 1000 remains unchanged for the price fact of installation2000.


-56-

As of 04.01.2003 contract 3000 will be billed with the new priceamount of 0.21.

3rd Step: Move-out (without master data generator)You execute a move-out for contract 3000 for 09.30.2003.

Result:


1000Fact


3000Contract

09.30.2003

1000/0.20

1000

The price fact for installation 2000 is automatically limited duringmove-out. The price itself remains unchanged. Prerequisite for this isthat you use an operand in which the indicator Contract-RelevantOperand is selected.

Contract 3000 is restricted to the move-out date.4th StepRun the master data generator and use the following values for the parameters:

Node category Parameter name ValueQPRICE PRICEKEY -QPRICE_HIST FROMDATE_PRIC

E10.01.2003

QPRICE_HIST AMOUNT_PRICE 0.19INSTALLATION_HISTORY



10.01.2003

INST_FACTS_QPRICE PRICEKEY -


-57-

MOVE_IN MOVE_IN_DATE 10.01.2003


-58-

Result:


1000Fact


3000Contract

10.01.2003

1000/0.20

1000

1005/0.19

3030

1005

A new price with the key 1005 is created for 10.01.2003.As of 10.01.2003, the price fact for installation 2000 has the new pricekey 1005.

The new contract 3030 is billed with the new price 1005. The old price1000 is no longer used.

Reference ValuesYou use the following sub-nodes to create the following types of reference values:

INST_FACTS_RVAL_STD ( add standard reference values)INST_FACTS_RVALLIGHT (add street lighting reference values)INST_FACTS_RVAL_HEAT (add heating installation referencevalues)

INST_FACTS_RVAL_CONT (add container reference values)INST_FACTS_RVAL_AREA (add area reference values)

You use the AB attribute to define the point in time as of which the reference value is valid.There is no attribute that you can restrict using the to-date. The processing of time slicesdiffers greatly from the processing of other installation facts.

The nodes named above constantly add new reference values.Existing reference values are not changed.


-59-

ExampleAn installation contains the following fact:

Operand RVAL1 (operand category REFVALUE)

Valid from 01.01.2000

Value 10.00

You create a master date template with the RATECHANGE category.The template uses INST_FACTS_RVAL_STD to add the following factto the installation:

Operand RVAL1 (operand category REFVALUE)

Valid from 03.01.2000

Value 15.00

You execute the MDT twice for the installation. The installation thencontains the following facts:

Operand RVAL1 from 01.01.2000 value 10.00 (number 0001)

Operand RVAL1 from 03.01.2000 value 15.00 (number 0002)

Operand RVAL1 from 03.01.2000 value 15.00 (number 0003)You cannot therefore use MDTs to change or delete existing reference values. insensitiveYou can use the INST_FACTS_RVAL_OPM master data template category to add one ormore operation types to a street light. You cannot change the operation types of existing streetlights.You can use the INST_FACTS_RVAL_TRE MDT category to allocate one or more audio-frequency ripple control receivers (ARCRs) to a new reference value. You cannot allocate anACRC to an existing reference value.You can use the INST_FACTS_RVAL_SVF MDT category to allocate a service frequency toa new container reference value. You cannot make any changes. If you maintain certainattributes, certain other attributes become required entry fields. For more information, see thenotes in SEV_FREQ_SERV_LOC.

- LPROF_INST_ASSIGN and LPROF_INST_FACTORYou can use LPROF_INST_ASSIGN to assign a synthetic load profile to a utility installation.You can also change and chronologically restrict an existing assignment. You cannot,however, delete an existing allocation.Load profile assignments are managed internally with a logical number. The attributeLOGLPRELNO corresponds to this logical number. If you execute this node and leave theattribute empty, a new assignment is created. If you maintain the attribute with the value of alogical number, the affected assignment is changed.The user does not generally know the logical number of the load profile assignment. They arenot displayed in the online transaction. The LOGLPRELNO_BY_PROFROLE attribute


-60-

(determine logical number of load profile assignment by role) makes it easier to makechanges. If you maintain this attribute with the value ‘X’ the master generator proceeds asfollows:

It ignores entries for the LOGLPRELNO attribute.The master data generator determines which Profile Allocation Role isspecified for the PROFROLE attribute.

It checks whether an assignment using this role exists for the utilityinstallation. If yes, then this assignment is changed. If not, the systemcreates a new assignment.

However, you can only set the LOGLPRELNO_BY_PROFROLE attribute if the role is usedin no more than one allocation for each utility installation. Otherwise you receive an errormessage from the master data generator.Alternatively, you can also set the value ‘X’ for the attribute LOGLPRELNO_BY_PROFIL.A prerequisite is, however, that you use a profile in no more than one assignment per utilityinstallation. The master data generator then proceeds as follows:

It ignores entries for attribute LOGLPRELNO.The master data generator determines that Determine Current No. ofProfile Alloc. Via EDM Profile No. is specified for the PROFILEattribute.

It checks whether an assignment with this profile exists for the utilityinstallation. If this is the case, the assignment is changed. If not, thesystem creates a new assignment.

ExampleTwo synthetic load profiles are allocated to one utility installation. One of the twoassignments has changed historically:

Logicalnumber ofassignment

From To Profile Role

4711 01.01.2002 30.06.2002 10001000 A1004711 01.07.2002 31.12.9999 20002000 A1004712 01.07.2002 31.12.9999 20002000 B100

You want to use the master data generator to change the assignment with the logical number4711. You have the following options:

You run the master data generator and maintain the attributeLOGLPRELNO with the value 4711. TheLOGLPRELNO_BY_PROFROLE andLOGLPRELNO_BY_PROFIL attributes remain empty.

You run the master data generator and set the attributeLOGLPRELNO_BY_PROFROLE to the value ‘X’ and thePROFROLE attribute to the value A100.


-61-

You cannot set LOGLPRELNO_BY_PROFIL for this utilityinstallation. This would lead to an error message.

In the case of a creation, the assignment begins with the date belonging to the AB attribute(from-date). The BIS attribute (to-date) is optional. If you do not maintain this attribute, theassignment is created without a chronological restriction.In the case of changes, the assignment is changed from the date belonging to the AB attribute(from-date). Periods before the from-date are not changed. The period after the from-date isdefined completely by the specifications of the master data generator. If the BIS attribute (to-date) is maintained, the assignment is limited to this to-date.Example: You run the master data generator with the following data for the aforementionedinstallation.

LOPGLPRELNO (logical number of assignment) = 4711AB (from-date) = 03.01.2002BIS (to-date) = 05.31.2002PROFILE (profile) = 30003000PROFROLE (role) = A100

The installation now has the following status regarding the synthetic load profiles:

Logicalnumber ofassignment

From To Profile Role

4711 01.01.2002 06.30.2002 10001000 A1004711 03.01.2002 05.31.2002 30003000 A1004712 07.01.2002 12.31.9999 20002000 B100

You use the attribute USEFACTOR of the node LPROF_INST_ASSIGN to specify the usagefactor of the load profile. This usage factor is valid as of the AB date (from-date). You canhistorically change usage factors, without affecting the actual assignment. The sub-nodeLPROF_INST_FACTOR is available for additional changes to the usage factor. You canactivate this node and further prorate the usage factor. Important: The from-date in nodeLPROF_INST_FACTOR must be more recent than the from-date in nodeLPROF_INST_ASSIGN.

DEVICE_BILL_INSTALL and REG_BILL_INSTALL

INSTALLATION contains the DEVICE_BILL_INSTALL sub-node. This MDT categoryenables the billing-related installation of one or more devices in the utility installation.DEVICE_BILL_INSTALL only has limited change functionality. DEVICE_BILL_INSTALLcan only work with existing devices. These devices can either be normal devices or deviceinfo records.DEVICE_BILL_INSTALL contains attributes at device level. The following attributes aremandatory:


-62-

With SERNR (device number) and MATNR (device category), youdefine which device you want to install. Alternatively, you can use theEQUINR attributes and specify the equipment number of the device.If you do this, you must set the MATNR and SERNR attributes totheir initial values or use the Do not change evaluation category.

The higher-level INSTALLATION node automatically transfers theANLAGE attribute (utility installation).

You use the REG_BILL_INSTALL sub-node category to maintain device installation data atregister level. You must activate this node for each register of the specified device- more thanonce if necessary. The mandatory attributes are:

ZWNUMMERE (register number), using which you specify theregister of the device to which the data refers. Ensure that you alwaysspecify a register number that matches the characteristics of thedevice. If you use a device with only one register, which is most oftenthe case, the number is 001. If you do not specify a register number,or specify an incorrect number, the values of the other attributescannot be allocated to the register.

With PERVERBR you maintain the period consumption of theregister.

With ZWSTANDCE you specify the meter reading during the billing-related device installation.

NoteSome attributes of DEVICE_BILL_INSTALL andREG_BILL_INSTALL are dependent on the division or registercategory. If in doubt you can orient yourself on the Billing-RelatedDevice Installation under Utilities Industry Device ManagementInstallation.

When you execute the node, the system first checks whether the device is allocated to theinstallation at the specified date. If the device has not yet been allocated, the billing-relateddevice installation is carried out. All the attributes of the MDT are then processed.If, on the other hand, the billing-related device installation has already been carried out, onlythe rate data of the MDT is transferred. In this case, the DEVICE_BILL_INSTALL andREG_BILL_INSTALL master data template categories change the rates for the device andregister data.

In the case of a rate change, only a part of the attributes is processed. In theREG_BILL_INSTALL, the values of the following attributes for the installed register aretransferred:

TARIFART rate typeKONDIGRE fact group


-63-

GVERRECH pay clearing pricePREISKLAE price class

All the other attributes are ignored. Particularly, if the above-mentioned rate data is changed,no meter reading result is transferred. This restriction is not disadvantageous since theproduct-related rate data is generally covered by the above-mentioned data. The advantage is,when you execute the MDT in order to change the rate data, you do not have to enter meterreading results.Below are some notes on the KENNZIFF code attribute, which is used to identify the register.This code has a role in three MDT categories:

If you use the REGISTER_INFO MDT category to create a device inforecord, the default value for the code is taken from the register group.You can use the KENNZIFF attribute to overwrite the value.

If you use the REG_TECH_INSTALL MDT category to technicallyinstall a normal device, you can use the KENNZIFF attribute tochange the value of the code If you do not, the default value from theregister group is retained.

Billing-related device installations using REG_BILL_INSTALL alsouse the KENNZIFF attribute. However, you cannot change the valueof the code. The attribute is only used by the environmentdetermination function. This function can use the code to determinethe node to which the REG_BILL_INSTALL node belongs. This isespecially important if you use devices that have more than oneregister.

Below is an example that shows how the environment determination functions uses theKENNZIFF attribute:

You create an MDT for customers that have a double-rate meter. Youactivate the DEVICE_INFO node and replicate the REGISTER_INFOnode. In the first node, you use the KENNZIFF attribute to set the“On-peak meter for active energy” code; in REGISTER_INFO set the“Off-peak meter for active energy” code.

You activate the REG_BILL_INSTALL node twice and set the “On-peak meter for active energy” or “Off-peak meter for active energy”values in the KENNZIFF attributes.

You use the MDT for an initial data creation. Two registers with theabove codes are created and installed. The environment determinationfunction and the codes in the REG_BILL_INSTALL node have norole.

You now execute the same MDT for an existing installation in which adouble-rate meter has already been installed. The rate data of theMDT is to be copied for the registers. This is made possible by theenvironment determination function, and you do not have to explicitlyspecify the device number and register number. The environment


-64-

determination function compares the codes in theREG_BILL_INSTALL nodes with the values of the registers andthereby creates the link.

As mentioned above, the register number is defined using the ZWNUMMER attribute. As ofIS-U Release 4.64, you can also use the additional attribute DEF_ZWNUMMER to determinethe register number. The value of the DEF_ZWNUMMER attribute is then used if attributeZWNUMMER does not have a value.

ExampleYou use a master data template with which you can execute a billing-relatedinstallation of a device with two registers in an installation.

Activate twice the node for the billing-related installation of a register. The first nodeinstalls a register with the rate data for an on-peak register. The second node installsa register with the rate data for an off-peak register.

At the first node, select the data source Parameter for the E_ZWNUMMER attribute.You select the parameter name HT_ZW. Select the data source Constant for theDEF_ZWNUMMER attribute, and enter the value 001.

At the second node, select the data source Parameter for the E_ZWNUMMERattribute. You select the parameter name NT_ZW. Select the data source Constantfor the DEF_ZWNUMMER attribute, and enter the value 002.

You run the master data template, in order to create a utility installation and toexecute a billing-related installation of a double-rate meter. The parameters HT_ZWand NT_ZW are not maintained.Result: Because the named parameters are empty, the constants from theDEF_ZWNUMMER attributes are used. Register 001 is installed as an off-peakmeter. Register 002 is installed as an off-peak meter.

You run the master data template again. In this case, an existing installation ischanged. The environment determination recognizes that a double-rate meter isinstalled in the installation. It uses the constants to identify that register 002 is theon-peak register, and register 001 is the off-peak register. It assigns parameterHAT_ZW the value 002 and NT_ZW the value 001. These values are used in thenodes. It ignores the specification in the DEF_ZWNUMMER.

- LPROF_REG_ASSIGNYou can use this sub-node for REG_BILL_INSTALL to allocate a load profile to an intervalmeter. You can also change and chronologically restrict an existing assignment. You cannot,however, delete an existing allocation.Load profile assignments are managed internally with a sequence number. The attributeLOGLPRELNO corresponds to this sequence number. If you execute this node and leave theattribute empty, a new assignment is created. If you maintain the attribute with the value of alogical number, the affected assignment is changed.The user does not generally know the sequence number of the load profile assignment. Theyare not displayed in the online transaction. The following two attributes make it easier tomake changes:


-65-

ROLENO_BY_PROFROLE Determine sequence number of profileallocation by role

ROLENO_BY_PROFILE Determine sequence number of profileallocation by EDM profile number.

The meaning of these attributes corresponds to that of LOGLPRELNO_BY_PROFROLE andLOGLPRELNO_BY_PROFILE for the attribute LOGLPRELNO. See the explanation andexamples in the section for LPROF_INST_ASSIGN and LPROF_INST_FACTOR.In the case of a creation, the assignment begins with the date belonging to the DATEFROMattribute (from-date). The DATETO attribute (to-date) is optional. If you do not maintain thisattribute, the assignment is created without a chronological restriction. If required you canalso use the TIMEFROM and TIMETO attributes to predefine the time at which theassignment is to start and end.In the case of changes, the assignment is changed from the time belonging to theDATEFROM and TIMEFROM attributes. The system does not change periods that lie beforethis time. The period after this time is completely defined by the specifications of the masterdata generator. If the DATETO attribute (to-date) is maintained, the assignment is limited tothis to-date.

- POINT_OF_DELIVERYYou can use the optional POINT_OF_DELIVERY sub-node to create or change a point ofdelivery.

If you use POINT_OF_DELIVERY in the NEWCUSTPOD,CRMPARTNERTECH or CRMNEWCONTRACT master datatemplate categories, the point of delivery is created by the higher-levelnode POD_STAND_ALONE. POINT_OF_DELIVERY is only usedto allocate the point of delivery to the installation.

If you use POINT_OF_DELIVERY in the NEWCUST, CONNOBJ,INSTALLATION, PREMISE or RATECHANGE MDT categories,you can also use POINT_OF_DELIVERY to create points of delivery.

When you create a new utility installation, enter the same date in the DATEFROM attribute(start date of the point of delivery) as in the AB attribute of the INSTALLATION_HISTORYnode. When you change an installation, you use this attribute to determine the date fromwhich the change is valid.

- CONTRACTYou can use the optional CONTRACT sub-node to create a contract for a utility installation.As already mentioned in the description of PREMISE; you can only use CONTRACT incombination with the MOVE_IN node. You can only create contracts in combination withMOVE_IN. Without MOVE_IN, you can only change existing contracts.To change an existing contract, you must enter the key of the contract to be changed in theVERTRAG attribute. If you want to create a contract, the VERTRAG attribute must remainempty. As of Release 4.64+, 4.71 and 4.72 you can, after you have run theISU_PRODUCT_IMPLEMENT function module, get the key for the new contract from the


-66-

export table XY_NEW_KEYS_TAB. A prerequisite is that you select the data source typeParameter for the VERTRAG attribute.As of the release after SAP IS-U 4.72, and by implementing the correction from SAP notenumber 745519, you can also enter values in the Contract Number from Legacy System(VREFER) and Move-In Date from Legacy System (EINZDAT_ALT) fields from the masterdata template category CONTRACT in the master data generator.

- BCONTACTYou can use the optional BCONTACT sub-node to create a customer contact. You cannot useBCTONTACT to change existing customer contacts.Provided a business partner can be uniquely identified in the MDT; the business partnerreference is transferred to the PARTNER attribute. You must specify a contact configurationin order to create a customer contact. If you leave the CTDATE and CTTIME attributesempty, the system copies the current date and time into these attributes.You can use the optional BCONTACT_NOTICE node to add a text to the customer contact.You also have the option of linking Business Objects with the customer contact. To do this,use the option BCONTACT_OBJECTS sub-node. Note that you must maintain the objectrole, object type and object key. The ACTMDGLOG attribute provides a special function.The current application log of this MDG is added to the customer contact, provided thisattribute contains the default value X and the other attributes are maintained as follows:

OBJECTROLE: PRODUCTLOGOBJECTTYPE: ISUPRODLOGOBJECTKEY: Blank character constant

Provided you use the customer contacts purposefully, you can run an evaluation over them ata later point in time.


-67-

2 Master Data Templates in Release 4.64The following master data template categories are not yet available for Release 4.64:

BP_IND_SECTORLPRICE, LPRICE_HIST, LPRICE_INST_ASSIGNQPRICE, QPRICE_HIST, QPRICE_INST_ASSIGNTPRICE, TPRICE_HIST, TPRICE_INST_ASSIGNLPROF_INST_ASSIGN, LPROF_INST_FACTOR,LPROF_REG_ASSIGN

CRMCONNOBJ_ALONE, CRMOUTLCONTRACT,CRM_POD_INST

The following master data template categories are only available as of Release 4.64:BP_TAXNUM, BP_COPY_PREM_ADDRMOVE_IN_BPCONTACT

2 Master Data Templates in Release 4.63In comparison with Release 4.64 MDT functionality, the following restrictions apply toRelease 4.63:Internal number assignment is not possible in device info records. Serial numbers cannot beassigned repeatedly.The following MDT categories are not yet available:

MOVE_IN_MRINST_FACTS_RVAL_AREASERV_FREQ_SERV_LOG


-68-

3 Master Data Templates in Release 4.62In comparison with Release 4.63 MDT functionality, the following restrictions apply toRelease 4.62:The following MDT categories are not yet available:

CRMCONNOBJCRMNEWCONTRACTCRMPODCRMPARTNERTECHCRMPREMISECRMTECHCONNOBJCRMTECHOBJINST_FACTS_RVAL_SRVMOVE_IN_BBPNBSERVICEOPAREANBSERVICEPROVRELMETHNEWCUSTPOD POD_STAND_ALONE


-69-

4 Master Data Templates in Release 4.61The MDG and MDTs are also available in Release 4.61. The version shipped with the Release4.61 has been substantially re-worked. To use this new version, you must import the AOSP013.

Caution

You must import Add-On Support Package 013 before you create MDTsand use the MDG. See also SAP note 352873.

Master Data Template CategoriesThe following master data template categories are not available in Release 4.61:

BCONTACTBCONTACT_NOTICEBCONTACT_OBJECTSDEVICE_BILL_INSTALLDEVICE_INFODEVICE_LOCATIONDEVICE_TECH_INSTALLINST_FACTS_RATETYPEINST_FACTS_RVALLIGHTINST_FACTS_RVAL_CONTINST_FACTS_RVAL_HEATINST_FACTS_RVAL_OPMINST_FACTS_RVAL_STDINST_FACTS_RVAL_TREPOINT_OF_DELIVERYREGISTER_INFOREG_BILL_INSTALLREG_TECH_INSTALL

Test Master Data TemplatesIn Release 4.62 you can use the maintenance transaction to test MDTs. This functionality isnot available in Release 4.61.

5.- is-u master data templates.pdf

Documents