Sap Isu Master Data Template

Stammdatenvorlagen zu Release 4.64

Cookbook IS-U Master Data Templates in Release 4.71

Cookbook Stammdatenvorlagen zu Release 4.64 SAP AG

© Copyright 2003 SAP AG. All rights reserved.

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

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

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks 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 USA and/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 Web Consortium, 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 technology invented 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 mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies.

Seite -2-

SAP AG Cookbook Stammdatenvorlagen zu Release 4.64

Icons

Icon Meaning

Caution

Example

Note

Seite -3-


Master Data Templates Cookbook

Contents Icons ................................................................................................................. 3

1 Master Data Templates in Release 4.71 ............................................................................ 5 1.1 Overview..................................................................................................... 5 1.2 What Are Master Data Template Categories?............................................ 9

1.2.1 MDTs and MDT Categories ............................................................................. 9 1.2.2 MDT Category Hierarchy ................................................................................. 9 1.2.3 Cardinality ...................................................................................................... 10 1.2.4 Autonomous MDT Categories ....................................................................... 11 1.2.5 Create or Change .......................................................................................... 11 1.2.6 Virtual Attributes ............................................................................................ 12 1.2.7 User-Defined Fields ....................................................................................... 12

1.3 Environment Determination ...................................................................... 13 ISU_ENVIRONMENT_PREMISE........................................................................... 14

General Information .............................................................................................. 14 Environment for Technical Master Data ............................................................... 14 Identifying Constants ............................................................................................ 14

1.4 Master Data Templates ............................................................................ 15 1.4.1 Example ......................................................................................................... 15 1.4.2 Create and Test Master Data Templates ...................................................... 17 1.4 3 Notes on the Parameters............................................................................... 19

1.5 Master Data Generator ............................................................................. 20 1.5.1 Customer Contact.......................................................................................... 20 1.5.2 Key for New Master Data............................................................................... 21

1.6 Error Handling in the Master Data Generator ........................................... 21 1.7 Description of Master Data Template Categories..................................... 21

1.7.1 NEWCUSTPOD............................................................................................. 21 1.7.2 NEWCUST..................................................................................................... 22 1.7.3 RATECHANGE.............................................................................................. 22 1.7.4 BPARTNER and CONTRACT_ACCOUNT ................................................... 23

- BP_PAYMENT.................................................................................................... 24 - BP_CCARD ........................................................................................................ 24 - BP_TAXNUM...................................................................................................... 24 - BP_IND_SECTOR.............................................................................................. 25 - BP_COPY_PREM_ADDR.................................................................................. 25 - BP_ADDRESS.................................................................................................... 25 - BP_PHONE ........................................................................................................ 25 - BP_FAX.............................................................................................................. 26 - BP_EMAIL .......................................................................................................... 26 - CONTRACT_ACCOUNT.................................................................................... 26

1.7.5 DEVICE_INFO and REGISTER_INFO.......................................................... 26 - DEVICE_INFO as of Release 4.64..................................................................... 27 - REGISTER_INFO as of IS-U-Release 4.64 ....................................................... 30 - DEVICE_INFO until IS-U Release 4.63 ............................................................. 32

1.7.6 QPRICE ......................................................................................................... 33 QPRICE_HIST...................................................................................................... 33

Seite -4-


Example 1 For Historical Price Changes .....................................................35

Example 2 For Historical Price Changes .....................................................36 Meaning of the Quantity Base .............................................................................37

QPRICE.............................................................................................................38 CRM Prices ...........................................................................................................38

LPRICE....................................................................................................................38 TPRICE....................................................................................................................38 1.7.7 CONNOBJ ......................................................................................................38 1.7.8 DEVICE_LOCATION......................................................................................39

- DEVICE_TECH_INSTALL and REG_TECH_INSTALL ......................................39 - SERV_FREQ_SERV_LOC .................................................................................40

1.7.9 POD_STAND_ALONE ...................................................................................41 1.7.10 PREMISE .....................................................................................................42

- MOVE_IN ............................................................................................................42 - MOVE_IN_BBP ...................................................................................................43 - MOVE_IN_MR.....................................................................................................45

1.7.11 INSTALLATION............................................................................................46 - INSTALLATION_HISTORY.................................................................................46 Normal Installation Facts .......................................................................................46

- Example: Individual Prices and Installation Facts........................................47 Reference Values ..................................................................................................52 - LPROF_INST_ASSIGN and LPROF_INST_FACTOR .......................................53 DEVICE_BILL_INSTALL and REG_BILL_INSTALL .............................................55 - LPROF_REG_ASSIGN.......................................................................................58 - POINT_OF_DELIVERY.......................................................................................58 - CONTRACT ........................................................................................................58

1.7.12 BCONTACT..................................................................................................59

2 Master Data Templates in Release 4.64...........................................................................59 2 Master Data Templates in Release 4.63...........................................................................59 3 Master Data Templates in Release 4.62...........................................................................60 4 Master Data Templates in Release 4.61...........................................................................60

Master Data Template Categories ..........................................................................60 Test Master Data Templates ...................................................................................61

1 Master Data Templates in Release 4.71

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

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

• •

Registration of a new customer with a service provider

Rate change that affects an existing customer

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

Seite -5-


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

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

Examples of possible applications are:

• • •

•

Sales processes in Sales and Distribution (SD) or CRM

Internet Self Service functions

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

Import of utility contracts concluded by a sales partner

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

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

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

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

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

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

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

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

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

Seite -6-


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

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

Seite -7-

http://help.sap.com/

http://help.sap.com/


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 function module. It transfers the key of the MDT and a list of values (name, address and so on) to the function module. These are used as the parameters of the MDT.

From the MDT and MDT category, the MDG infers the following: o Information on the IS-U master data to be changed/created. o Constant values with which the master data must be created. o Programs (scripts) for changing the master data.

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. The information below does not describe any scenarios involving the MDG. Instead, it describes the 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?

Seite -8-


1.2 What Are Master Data Template Categories?

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

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

•

•

•

• •

•

•

•

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

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

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

What programs are processed

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

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

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

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

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

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

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

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

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

You can find this transaction in the IMG under SAP Utilities → Customer Service → MDG → Define MDT. On the initial screen enter the required MDT category and choose Display Hierarchy.

Seite -9-


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

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

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

1.2.3 Cardinality The cardinality of a MDT category determines whether the nodes in the template category can be activated and deactivated. The cardinality of a template category can have one of the following values:

•

•

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

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

Seite -10-


•

•

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

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

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

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

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

1.2.5 Create or Change Each template category contains programs for processing the template. The system calls these programs by means of the MDG. Most of these programs can create new master data and change existing master data. Note that some template categories do not support a change mode.

Example The template category used to install a device in an installation for billing purposes does not have a change mode. This is appropriate since the corresponding dialog transaction cannot change data either.

Below, in the descriptions of the individual template categories, you can see whether a particular category enables you to change master data objects. Use the attribute that contains the key of the object to define whether you can execute the template in change or create mode.

Example The BPARTNER template category (business partner) contains the PARTNER attribute (business partner number). With this field you can do one of the following:

Seite -11-


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

• In the template for the PARTNER attribute, choose the evaluation category Parameter. The application that calls the MDG allocates a value to the parameter. Result: The system changes the business partner with the transferred key value.

• In the template for the PARTNER attribute, choose the evaluation category Parameter. The application that calls the MDG does not allocate a value to the parameter. Result: When you execute the template, the system creates a new business partner.

Note The system does not support external number assignment.

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

Example For a new installation you change an existing utility installation (for example, by allocating a new rate category) and create a new contract.

Note The master data generator does not support the deletion of objects. This also applies for subobjects. For example: You can create or change one or more addresses for a business partner. However, you cannot delete an existing address.

1.2.6 Virtual Attributes Use the Virtual evaluation category for virtual attributes. The value is then determined at run time. This task is executed by a user-defined function module, which you enter as an attribute value in the template.

Function modules for virtual attributes must have a pre-defined interface. For example, you can use the function module ISU_VIRT_ATTR_REGIO_DEMO (demo solution: meter reading unit as a virtual attribute) for your own solution. Note the documentation in the code for this sample solution.

1.2.7 User-Defined Fields Several template categories use an attribute beginning with #CI_. These attributes represent user-defined enhancement in the master data tables.

Example

Seite -12-


The PREMISE template category contains the #CI_EVBS attribute. It represents 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 the case if you include customer-defined fields for the premise in CI_EVBS. If you now create a template with the PREMISE category, the system offers the fields of the CI_EVBS structure as additional fields. This feature enables you to use the MDG to maintain user-defined fields.

1.3 Environment Determination One MDT can be used for simultaneously creating and changing objects. This flexibility is important in sales processes, for example. You can use an MDT for initial data creation (to create premises, installations and so on), or to change existing objects for a customer (to enter the 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 (for example a utility installation). If the ANLAGE attribute (key for the utility installation) in the INSTALLATION 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 define what is to be changed or created. However, MDTs can contain many objects: the connection object, premise, installations, devices and so on. The application called does not always know all the objects. Furthermore, some objects may be replicated; there may be two devices (on and off-peak meters), two installations (one for the supplier and one for the distributor) and so on.

This situation requires a function that identifies existing objects and allocates them to the respective nodes. We call this function environment determination.

Example:

•

•

•

•

•

The MDT is only called with the key of the premise. If the premise already has utility installations then the keys of these installations are determined.

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

It must be ensured that the existing installation of the distributor can be distinguished from the existing installation of the supplier and allocated to the correct node. This is made possible by comparing identifying constants in the MDT with the values in the respective installation.

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

ISU_ENVIRONMENT_PREMISE is run in the MDT categories NEWCUST, NEWCUSTPOD and RATECHANGE. It is only active if you keep to the conventions of IS-U sales processing for Release 4.62 on the SD platform.

ISU_MDG_READ_ENV_UI is run in the MDT category CRMNEWCONTRACT. It is used in the IS-U/CRM integration solution. For more information, see the cookbook Integration of Sales Processes Between IS-U 4.63 and CRM 3.0 in the Service http://service.sap.com. The information below is restricted to ISU_ENVIRONMENT_PREMISE.

Seite -13-


ISU_ENVIRONMENT_PREMISE

General Information A utility product references a point of delivery, thereby referring to a utility installation. This is 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 a complete interface from which you can choose a subset. You can enter data in the subset. You can also refer to existing structures. To do this, ensure you specify the key of the affected object and that it is transferred to the corresponding key field.

Environment for Technical Master Data The environment determination function is used in generating quotations and for the sale of utility products. It finds existing structures and enters key from the corresponding parameter fields in the MDG. This ensures that existing objects are re-used.

The NEWCUST, NEWCUSTPOD and RATECHANGE product categories contain the ISU_ENVIRONMENT_PREMISE function module. This function module can search for objects in the technical master data (such as installation, installation facts, devices, and registers) 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-U installation found on the first level.

Identifying Constants In the MDT, you can, after activating the environment determination function, create a parameter of the identifying constants category. This value defines the criteria by which different objects of the same category can be selected. Without this parameter, the system cannot search for the objects.

Seite -14-


Figure 3: Identifying constants in MDT maintenance

When you create the NEWCUSTOMER MDT, the system examines the data in the SERVICE field and compares it with the entries in the technical master data for the business partner. If there is a utility installation with the value 002 then the key of that installation is automatically entered in the VSTELLE field.

If there is more than one installation with this value then the system asynchronously proposes a dialog. This dialog allows the user to choose one of the objects found and resume the process at the point where it was interrupted.

1.4 Master Data Templates

1.4.1 Example Below is an example of a MDT. Following this example is a description of the individual MDT categories. The example explains the links between template categories and templates.

The NEW_PARTNER MDT was created with the BPARTNER template category. This template creates a business partner and a contract account.

Seite -15-


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 has been created:

•

• •

• •

•

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

The Address node was activated once.

The Telephone number sub-node was replicated. The system creates the business partner with two telephone numbers. If these nodes are dynamic (dynamic nodes must have at least one attribute relevant to execution 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 Parameter evaluation category. The Val. (value) column contains the VKONT parameter. The MDG therefore searches the parameter list for a parameter with this name. The value of this parameter is then adopted by this attribute when you execute the template.

Seite -16-


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

•

•

•

•

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

The Business partner number (GPART) has the evaluation category Key reference. When you execute this attribute, the MDG automatically allocates the key of the previously changed or created business partner.

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

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

1.4.2 Create and Test Master Data Templates You can find this transaction in the IMG under SAP Utilities → Customer Service → MDG → Define MDT.

Note When you maintain the MDTs, we recommend that you open a second session to test the function you are using. For example, if you are creating a business partner, the test session enables you to view the content of individual fields and determine the fields to which default data can be successfully assigned.

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

can maintain. As a rule, the attributes in MDT maintenance correspond to those on the screen in the relevant master data function. The attributes are also in the same order, though exceptions may occur. For example, if you enter a division in the master data function then the entries in other fields are affected.

- You can make use of the checks in the functions. For technical reasons you cannot check the constants in the maintenance transaction for the MDT. - The master data function shows you what fields are mandatory. The master data

function shows you what fields are mandatory. Attributes that have fields marked with Mandatory (attribute is mandatory) may have additional fields whose entries are dependent on data in other fields. When you activate a node, the mandatory attributes are first given the status ‘red’. This shows the user that, as a rule, he/she requires a constant or a parameter for these attributes. However, you can also select Do not change for mandatory attributes. The Mandatory indicator is only a general rule, which does have exceptions. For example: The attributes for the first name and surname are mandatory for a business partner. However, if you use the template to create a business partner

Seite -17-


from the Organization category other attributes are mandatory. If you have any doubts, refer to the respective master data transaction.

The maintenance transaction also enables you to test your MDTs. In the initial screen, choose the Test template pushbutton to execute your template.

First, the system edits the parameters of the MDT. Enter an appropriate value. You can leave non-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 master data template. This is particularly useful if the template contains dynamic nodes. The overview shows which nodes are executed when you select the parameters. It is possible to navigate to the function module that is run when the master data generator is executed. This is done by selecting the columns Open Script, Modify Script or Save Script. This allows you to easily set breakpoints.

As of IS-U Release 4.71, the pushbutton Copy Key is available. It is only available when you recall the test function in the same mode. It copies the key created in a previous test run to the parameter of the same name. Example:

• You execute a master data template of the category CRMPARTNERTECH. The attribute that belongs to the key of the point of delivery has the parameter name P_INT_UI. Amongst other things, the master data template creates a new point of delivery.

• Still in transaction EPRODCUST, you now select a template from the category CRMNEWCONTRACT. Here, the system uses the same parameter name P_INT_UI for the key for the point of delivery.

• Select Copy Key. The system takes the key for the point of delivery created in the first run and transfers it for parameter P_INT_UI. You must no longer manually complete the parameter.

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

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

Caution

When you test an MDT, the system creates or changes master data. These changes 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 were created or changed. If an error occurred during execution, the log contains information on the reason for the error.

The Flow information shows you a list of all the programs executed by the MDG. You can navigate in the coding of these programs. Experts can use this navigation to set break points in the coding. Icons indicate whether each master data object was created or changed. An icon also indicates errors.

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

Seite -18-


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

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

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 the parameter 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 can then define these parameters in Customizing. All the parameters from the utility product are defined in the header data as external.

The colors preceding the nodes denote the status of the node. They are as follows:

• •

Green: Parameter assigned

Yellow: Parameter assigned several times

Seite -19-


• Grey: Parameter not yet assigned.

Note For the Create sales order transaction, use parameters from the utility product/material only. Use the field names from the template category for test purposes only.

Fig. 6: Maintain Master Data Templates

1.5 Master Data Generator

1.5.1 Customer Contact When you execute a template using the MDG, the system checks whether a business partner is linked to the template.

Seite -20-


•

•

If the MDT contains a node with the BPARTNER category (business partner), the system identifies the relevant business partner.

If not, the system searches for a node with the INSTALLATION category. The system can determine a business partner from the relationship between the utility installation to the contract and contract account.

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

→ Program context SAPLEPD_IMPLEMENT, sub-context ‘0001’.

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

1.5.2 Key for New Master Data After the master data template has been executed, you can use the log to find out which master data was generated. If, during subsequent processing, you need the keys for the generated or changed master data, you can use the export parameter XY_NEW_KEYS_TAB from the function module ISU_PRODUCT_IMPLEMENT.

The keys for the master data correspond with attributes in the master data template, in which the field KEYATTR Key Attribute is marked in the master data template category. For most nodes, these keys are transferred in the table XY_NEW_KEYS_TAB. A prerequisite is that you select the data source type Parameter for these attributes.

1.6 Error Handling in the Master Data Generator Various errors can occur when executing the master data generator, such as invalid parameter values, blocked objects or templates that contain errors. For a description of the procedure in the case of errors, see the cookbook Error Handling in SAP IS-U for Utility Contracts and Technical Objects from CRM in the SAP Service Marketplace, www.service.sap.com. Select Login Now and then use your user name and password. Now select Solution Details → Industry 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 Categories The 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 template categories. All other independent template categories are contained as subnodes in these categories. However, you can also use the other independent template categories to define master data templates. In addition, several independent template categories exist, which are important for IS-U/CRM integration. This document does not give further details of these categories.

1.7.1 NEWCUSTPOD

Note NEWCUSTPOD is the most comprehensive MDT category. You can use NEWCUSTPOD for initial data creation with the following objects:

• Business partner and contract account

Seite -21-

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


• • • •

•

•

•

•

Device information record

Connection object, device location, premise, point of delivery

Utility installation, installation facts

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

Move-in, contract, business partner contract

You can use transaction EPDHIER to show the hierarchy for this template category. You can see from the hierarchy that the cardinality supports a variety of scenarios.

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

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

You can replicate nodes- together with their sub-nodes on different levels.

Example

You create a connection object and premise. You replicate the nodes for the utility installation. You maintain the sub-nodes of both utility installation nodes. The MDT then creates two utility installations and two contracts.

•

• • •

To carry out initial data creation in two separate steps, create two templates with category NEWCUST. The first template carries out the first stage of processing; the second part finishes off processing at a later date.

See below for more information on the individual nodes.

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

You cannot create a point of delivery without an installation

You cannot create a point of delivery and use it in more than one installation

You cannot define services for the point of delivery

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

1.7.3 RATECHANGE The RATECHANGE MDT category is suitable for changing rate data in an existing installation. It previously contained the two sub-nodes BCONTACT and INSTALLATION_CHANGE. You can use this MDT category to change the rate category and facts of an installation, for example. As of Release 4.64 you can also change the rate data of an installation structure. To do this, see the notes mentioned in the descriptions of DEVICE_BILL_INSTALL and REG_BILL_INSTALL.

The INSTALLATION_CHANGE sub-node corresponds to the INSTALLATION MDT category, with which a utility installation is created. There are the following differences:

Seite -22-


•

•

•

•

•

•

INSTALLATION_CHANGE does not have the attributes for division and premise, since these cannot be changed. You can use INSTALLATION_CHANGE to change the other, non-historical attributes for an installation.

The hierarchy of INSTALLATION_CHANGE does not have the CONTRACT sub-node (create contract) and DEVICE_BILL_INSTALL (perform billing-related device installation in an installation). These categories can be used when an existing 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_ACCOUNT Using an autonomous template category, you can create a business partner in the role of a contract partner and then make changes to it. Note that restrictions apply to the changes. Also note the roles of the following attributes:

BU_GROUP (grouping) controls the allocation of numbers. Always use a grouping that allocates internal numbers. MDT categories do not support external number allocation.

TYPE determines the business partner category. If you create a business partner in dialog using the Create business partner transaction, you must enter the business partner category on the initial screen. The category you choose determines the selection of fields the system displays on the next screen. In the MDT, you must maintain the attributes that correspond to the business partner category you have chosen. For more information, see the documentation in the transaction.

With the NAME_FIRST and NAME_LAST attributes, you enter the first and last names of the business partner. These attributes are mandatory.

You can use the attribute VALDT to define that a change to a business partner should take effect at a later date (planned changes). If you do not use this attribute, the change becomes effective immediately. If you enter a date that lies in the future, the change becomes effective as of this date. To do this, the change must be transferred to the master data using a special batch report. You cannot specify a date in the past. The attribute VALDT is not included when you recreate a business partner.

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

o In the case of Organization use the NAME_ORG1 to NAME_ORG4 attributes

o ? In the case of Group use the NAME_GRP1 and NAME_GRP2 attributes.

• The XSEXM and XSEXF mandatory attributes determine the gender of the business partner. How you use these attributes depends on the business partner category.

Seite -23-


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 Release 4.71, the attribute XSEXU is also available (gender of business partner is unknown).

o In the case of an organization or group, leave the aforementioned attributes empty. This means you must leave the value empty and not change the evaluation category.

Templates that change the data of existing business partners can also use BPARTNER. 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 these attributes, select the Allocate value in creation mode only field.

Use the Do not change evaluation category for all other fields whose values you do not want to change. Use the Parameter attribute for all attributes you want to change (such as MARST (marital status) or JOBGR (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 address number is changed.

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

- BP_PAYMENT Using the optional BP_PAYMENT sub-node, you can maintain the bank details of a business partner. To create more than one set of bank details, replicate BP_PAYMENT. You differentiate between the sets of bank details by the different bank details ID. You enter these in the BKVID attribute.

BP_PAYMENT also allows you to change the bank details of existing business partners.

If you execute BP_PAYMENT with new bank details ID then a new set of bank details is created for that business partner.

If you execute BP_PAYMENT with a business partner’s existing bank details ID then these details are changed.

You cannot delete bank details.

- BP_CCARD Using the optional BP_CCARD sub-node, you can maintain a business partner’s payment cards. You do this in the same way as described above for BP_PAYMENT. Payment cards are 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 business partner. The system stores the tax number with a tax number category. You can activate the node several times

Seite -24-


and can maintain several tax numbers. However, only one tax number is allowed per tax number category. You can also allocate a new tax number to an existing tax number category.

- BP_IND_SECTOR Using the optional node BP_IND_SECTOR you can allocate one or more branches to a business partner from the Organization category. You cannot use this node for business partners from the categories Natural Person or Group.

Note: Up to, and including IS-U Release 4.64 it was possible to use attribute IND-SECTOR from the BPARTNER node to maintain the branch. For IS-U Release 4.71, the new node BP_IND_SECTOR replaced this attribute.

- BP_COPY_PREM_ADDR Using the optional node BP_COPY_PREM_ADDR you can transfer the address of a premise as a new address of a business partner.

- BP_ADDRESS Using the BP_ADDRESS sub-node, you define the address data of a business partner. When you create a new business partner, you can supply one or more addresses. If you create more than 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 the ADDRNUMBER attribute (address number) empty. If you want to change an existing address for an existing business partner, you must transfer the address number in this attribute.

The address number is an internal field and is not displayed in dialog transactions. If you call the MDG from one of your own applications and want to change addresses then you must determine the address number beforehand. You can use the ISU_DB_PARTNER_SINGLE function module to determine address numbers. When you call this function module, set the X_XADDR_MULT indicator.

If you try to create a business partner without an address, the system generates an error message. 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 a new 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 business partner’s address may be changed when you perform the move-in. For more information, see your Customizing settings under SAP Utilities → Customer Service → Process Execution → Move-In/Out → Move-In → Define Move-In Control Parameters on Document Level.

- BP_PHONE BP_PHONE is an optional sub-node of BP_ADDRESS. For each address, you can create one or more telephone numbers. If you create more than one then set the FLGDEFAULT attribute for 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 in the CONSNUMBER attribute or use the initial value 000.

You can also change existing telephone numbers. To do this, you must have entered the address number in the ADDRNUMBER attribute in the BP_ADDRESS higher-level node. In the 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 of address number and current telephone number are permitted:

Seite -25-


BP_ADDRESS ADDRNUMBER

BP_PHONE CONSNUMBER

Effect

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

not initial initial The system adds a new telephone number for an existing address

not initial not initial (001, 002, ...)

The system changes a telephone number for an existing address

initial not initial Not allowed !

The same logic applies to the BP_FAX and BP_EMAIL

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

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

- CONTRACT_ACCOUNT With CONTRACT_ACCOUNT you create one or more contract accounts for the business partner. You can also change existing contract accounts. The template category is not autonomous. If you want to create a contract account for an existing business partner, proceed as follows:

1. Activate the BPARTNER node. Set the evaluation category Do not change for all attributes. Only select the evaluation category Parameter for the PARTNER attribute. 2. Activate the CONTRACT_ACCOUNT sub-node of BPARTNER only. The system automatically adopts the key of the business partner from the business partner node.

You can use the VALDT attribute to execute planned changes to the contract account. For further information see the explanations for attribute VALDT in the BPARTNER node.

1.7.5 DEVICE_INFO and REGISTER_INFO For 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 function corresponds to the Create device info record transaction, which can be found under Utilities Industry → Device Management → Installation → Device Info Record. Each time you execute DEVICE_INFO a new device info record is created. Existing device info records cannot be changed.

The template category DEVICE_INFO is autonomous. It is also part of the hierarchy of the NEWCUSTPOD template category. During initial data creation with NEWCUSTPOD, you can create device info records and then install them (billing-related) in an installation.

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

Seite -26-


- DEVICE_INFO as of Release 4.64 You use the KEYDATE and SPARTE attributes to define the date on which the device info record is created and with which division.

The MATNR attribute defines with which device category the device info record is created. »You cannot use device categories in which the Device Info Record field contains the Only Devices Permitted entry.

You use the SERNR attribute to define the device number with which the device info record is created. If you maintain the SERNR attribute then the number is assigned externally. Note that you cannot yet use a combination of SERNR and MATNR. In the device category, the Device 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 indicators in Customizing under SAP Utilities → Device Management → Installation → Device Info Record → Define System Parameters for Device Info Record.

DEVICE_INFO does not export the new device numbers. If you define a parameter for the SERNR attribute, the new device number is not allocated to the parameter.

The EQUNR attribute corresponds to the equipment number. Equipment numbers are always assigned internally. They are also always unique, even if the device number is ambiguous. If you use a parameter for the EQUINR attribute and a new device info record is created, the value of the new key is assigned to the parameter.

As already mentioned, DEVICE_INFO only creates device info records and cannot change existing ones. However, some applications require that the master date template be run several times. In the case of other objects, the object is changed if you transfer its key to the MDT. If you call the BPARTNER node (business partner) with a value for the PARTNER key, the corresponding business partner is changed. However, since DEVICE_INFO cannot carry out a device modification, the following logic is used instead:

•

•

If, when you call DEVICE_INFO, you allocate a value to the EQUINR attribute, a new device info record is not created. The system only checks whether a valid device info record exists for the transferred equipment 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 device info record is not generally created. Note however the following exception: o You have maintained the SERNR attribute. A device info record already

exists for device number SERNR and device category MATNR on the key date (KEYDATE attribute).

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

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

DEVICE_INFO is frequently used together with the DEVICE_BILL_INSTALL node. You can use DEVICE_INFO to create a device info record and then use DEVICE_BILL_INSTALL to install it (billing-

Seite -27-


related) in an installation. You should use the equipment number to link these two nodes. This has two advantages: the link functions when you use internal number assignment as well as in cases of ambiguous device numbers. It also supports a limited change mode.

The interaction of DEVICE_INFO and DEVICE_BILL_INSTALL is illustrated in the examples below.

Example 1: External Number Assignment You create an MDT with the NEWCUSTPOD category and maintain the following attributes in the DEVICE_INFO and DEVICE_BILL_INSTALL nodes:

Node Attribute Data Source Value

DEVICE_INFO SERNR Parameter SERNR1

DEVICE_INFO MATNR Constant 1000

DEVICE_INFO EQUNR Parameter EQUNR1

DEVICE_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 Value

SERNR1 5432

EQUNR1 (no value)

Result:

•

•

In the DEVICE_INFO node, the MDT creates a device info record with device number 5432 and device category 1000. A new equipment number, 17400 is assigned. Prerequisite: The device category either permits ambiguous number assignments or there is no device 5432 for this device category.

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

Note: you can choose a different type of value allocation, for example by parameter, for the MATNR attribute (device category). However, you must ensure that the device category always 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 Value

SERNR1

EQUNR1 17400

Result:

Seite -28-


•

•

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

DEVICE_BILL_INSTALL recognizes that equipment 17400 has already been installed (billing-related) in the installation. The node therefore 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 not have changed processing.

Example 2: Internal Number Assignment You create an MDT with the NEWCUSTPOD category and maintain the following attributes in the DEVICE_INFO and DEVICE_BILL_INSTALL nodes:


DEVICE_INFO SERNR Do not change


DEVICE_INFO EQUNR Parameter EQUNR1

DEVICE_BILL_INSTALL SERNR Do not change

DEVICE_BILL_INSTALL MATNR Do not change

DEVICE_BILL_INSTALL EQUNR Parameter EQUNR1

Operation a):

Parameter Value

EQUNR1 (no value)

Result:

• As in example 1a, a new device info record with the equipment number 17401 is created and installed. The device number is assigned internally.

Operation b):

Parameter Value

EQUNR1 17401

Result:

• As in example 1, only the rate data is changed in existing installed device info records.

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


Seite -29-


DEVICE_INFO SERNR Parameter SERNR1


DEVICE_INFO EQUNR Do not change

DEVICE_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 Value

SERNR1 5433

Result:

•

•

In the DEVICE_INFO node, the MDT creates a device info record with 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 Value

SERNR1 5433

Result:

•

•

•

•

•

DEVICE_INFO recognizes that there is already a device info record with 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 externally assigned. The template cannot be called if the device number (SERNR) has not been maintained. In the same way, device installations with DEVICE_BILL_INSTALL are terminated if the device number is left empty.

MDTs with this structure cannot be used for device categories with ambiguous device numbers. Device installations that used DEVICE_BILL_INSTALL are terminated because no device can be uniquely identified.

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

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

The register group for the device category (MATNR) is determined.

Seite -30-


•

•

In the register group, the system checks for registers in which the field Propose register during installation/replacement is selected.

If this field is not selected in any of the registers, the device info record is created with all the registers of the register group. If the field is (partially) selected, the device info record is created with the selected registers. The attributes of the register group (register category. unit of measurement for meter reading and so on) are adopted unchanged.

Example You enter the device category 1000 in the MATNR attribute. The corresponding register group has two consumption registers. The Propose register during installation/replacement field is selected in both registers. You do not activate the REGISTER_INFO node. When you execute DEVICE_INFO, a new device info record with two consumption registers is created. The device info record’s characteristics match those of the register group.

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

Example You enter the device category 1000 in DEVICE_INFO. In the second register, unlike the specifications in the register group, you want to have two decimal places. To do this proceed as follows:

1. You activate the REGISTER_INFO node.

2. In the ZWNUMMER attribute (register number) enter the constant value 002.

3. In the STANZNAC attribute (decimal places) enter the constant value 2.

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

5. If you want to change register 001 then you must replicate the REGISTER_INFO node.

Note Several attributes can only be used depending on the division or register category. If in doubt, you can orient yourself on the Create device info record transaction.

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

Example:

Seite -31-


•

•

You activate the DEVICE_INFO and enter device category 1000 for the MATNR attribute. This device has a register group with four registers. The first three registers are default registers; register 004 is not.

You activate the REGISTER_INFO node with the following values:


REGISTER_INFO ZWNUMMER Constant 002

REGISTER_INFO DO_NOT_USE Do not change

REGISTER_INFO STANZNAC Constant 3

• You activate the REGISTER_INFO node with the following values:



REGISTER_INFO DO_NOT_USE Constant X

• You activate the REGISTER_INFO node with the following values:



REGISTER_INFO DO_NOT_USE Constant

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

•

•

•

•

Register 001 is created with the characteristics of the register group, since it the default register and you have not engaged the override functions.

Register 002 is also created. If you choose the Do not change option for the DO_NOT_USE attribute, the register is only created if the register groups stipulates that it is a default register. This is the case here. The register is created with 3 decimal places (STANZNAC attribute).

Register 003 is not created, although the register group stipulates that it is a default register. This is because the DO_NOT_USE = ‘X’ attribute overrides the register group.

Register 004 is not created, although the register group stipulates that it is 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 which registers are created. If you install the device info record (billing-related) after creation, you must of course ensure that there are REG_BILL_INSTALL nodes to match the existing registers.

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

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

Seite -32-


•

•

•

•

•

•

•

•

•

Ambiguous device numbers are not permitted. In the SERNR and MATNR 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 (information field) attributes.

DEVICE_INFO causes an error message if the device info record belonging to DSERNR and MATNR already exists. This was changed in Release 4.63 with OSS note 459827. If the device info record already exists, a warning is recorded in the log. Processing is not terminated.

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

1.7.6 QPRICE Using the QPRICE and QPRICE_HIST nodes you can create or change a price from the price category Quantity-Based Price. You cannot delete prices details. Use the QPRICE node to define the attributes of the price header. QPRICE_HIST is used to define the historical price amounts. This MDG function is particularly useful for maintaining customer-specific prices that are only valid for a specific contract. See also the section Example: Individual Prices and Installation Facts.

You can also use the node from the QPRICE and QPRICE_HIST category to change existing prices. It is possible to make changes to a price header. However, the changes are generally made to the price amounts. For example, it is possible to add a new price time slice to an existing price.

The attributes for the QPRICE node correspond to the fields in the price header. The attributes CUT_PAST, CUT_FUTURE and MNGBASIS_CONVERT are exceptions, which control the processing of historical price data.

QPRICE_HIST The QPRICE_HIST node has the following attributes:

The mandatory attribute ABDATUM determines the date from which the price is valid.

The BISDATUM attribute determines the end of the validity period for the 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 for prices with the Block Price or Scale Price price type. Leave this attribute empty 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 is set 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 system sets the value to “1”.

Use the attribute PREISBTR to maintain the price amount. Use the attribute TWAERS to transfer the corresponding currency. You can create price amounts in different currencies for the same price header.

Example: You use the master data generator to create a price with

Seite -33-


currency 1. You then recall the master data generator to change this price. You enter currency 2 in the TWAERS attribute. As a result, the price now has two currencies. The price amounts for the first currency are not changed when you call the master data generator for the second time.

Note

For the price history attributes, Do Not Change has the same meaning as Data Source = Constant and Value = Initial Value. You can also create a master data template that only changes the price’s quantity base, but uses Do Not Change to 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, and specify different values for the from-date. In the following, the earliest from-date is called the Start Date.

The node with the most recent from-date uses the to-date to determine the End Date. If you do not maintain the optional to-date, then the end date is set to 12.31.9999. If the to-date has a final value, this value is adopted 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 the online transaction. If the master data template contains more than one time slice, the old time slice is always extended to the from-date for the next time slice. For this reason, only the to-date from the most recent 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 start date.

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

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

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

Seite -34-


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 all blocks. You cannot change just one of a number of blocks.

Example 1 For Historical Price Changes

For the purpose of this example, the price with the key 1000 has the following historical price amounts:

From-date To-date Price amount

01.01.2003 31.03.2003 1,40

01.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 Value

QPRICE PREIS (price key) 1000

QPRICE CUT_PAST -

QPRICE CUT_FUTURE -

QPRICE_HIST (first node) AB (from-date) 01.06.2003

QPRICE_HIST (first node) BIS (to-date) -

QPRICE_HIST (first node) PREISBTR (price amount)

1.60

QPRICE_HIST (second node) AB (from-date) 01.08.2003

QPRICE_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 price amounts:


01.01.2003 31.03.2003 1.40

01.04.2004 31.05.2003 1.50

01.06.2003 31.07.2003 1.60

01.08.2003 31.12.9999 1.70

Graphic:

Seite -35-


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 Changes

For the purposes of this example, the price with the key 1000 has the same conditions as in example 1. You change this price again, using the master data generator, then run a template with the following values:

Node Attribute Value

QPRICE PREIS (price key) 1000

QPRICE CUT_PAST X-

QPRICE CUT_FUTURE X

QPRICE_HIST (first node) AB (from-date) 01.06.2003

QPRICE_HIST (first node) BIS (to-date) -

QPRICE_HIST (first node) PREISBTR (price amount)

1.60

QPRICE_HIST (second node) AB (from-date) 01.08.2003

QPRICE_HIST (second node) BIS (to-date) 30.09.2003

QPRICE_HIST (second node) PREISBTR (price amount)

1.70

Seite -36-


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


01.06.2003 31.07.2003 1.60

01.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 existing historical price data is not prorated, but is deleted. The system only saves the periods that are covered by the master data generator.

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

Meaning of the Quantity Base

The quantity base, to which the price amount refers, is located in the MNGBASIS attribute of the node QPRICE_HIST. The MNGBASIS attribute is optional. If you do not use the attribute, the price is created with the quantity base 1.

In addition, the QPRICE node contains the MNGBASIS_CONVERT attribute. When you use this attribute you activate a conversion of the price amount to this quantity base, in the master data generator. The master data generator converts the price amount (PREISBTR attribute in QPRICE_HIST node) from the quantity base MNGBASIS of the QPRICE_HIST node to the quantity base MNGBASIS_CONVERT of the QPRICE node.

Seite -37-


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

Node category Attribute Value QPRICE MNGBASIS_CONVERT 1

QPRICE_HIST MNGBASIS 1000

QPRICE_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 to the attribute for the price amount (here 143.25 has only 2 decimal places). This is particularly useful in connection with the CRM integration. This is because, in CRM, only as many decimal places are available for prices as are available for amounts (as a rule, only 2 decimal places).

Note Important restrictions: If you use attribute MNGBASIS_CONVERT you can only use the values 1, 10, 100, 1000, 10000, and so on, for this attribute and the MNGBASIS attribute. This restriction ensures that only decimal places are moved during the conversion. A different conversion (such as quantity base 3 to quantity base 1) could lead to rounding errors.

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

•

•

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

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

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

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

1.7.7 CONNOBJ For 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.

Seite -38-


The DEVICE_LOCATION sub-node enables you to create a device location. The device location is automatically allocated to the connection object.

Using the optional PREMISE sub-node, you can create one or more premises for your connection object. The premises are automatically allocated to the connection object. You can also create new premises for existing connection objects.

1.7.8 DEVICE_LOCATION For an overview of the hierarchy of DEVICE_LOCATION , see the description of NEWCUSTPOD.

You can use the autonomous MDT category DEVICE_LOCATION to create or change a device location. DEVICE_LOCATION is part of the hierarchy of CONNOBJ (connection object) and thereby NEWCUSTPOD (initial data creation).

You use the HAUS attribute (connection object) to allocate the device location to a connection object. If you want to change an existing device location, this attribute is mandatory. In the case of templates with the category CONNOBJ or NEWCUSTPOD the key of the higher-level connection object generated in the hierarchy is automatically used. You can also use DEVICE_LOCATION to allocate more than one device location to a connection object. You cannot explicitly allocate a device location to a premise.

- DEVICE_TECH_INSTALL and REG_TECH_INSTALL DEVICE_LOCATION contains the sub-category DEVICE_TECH_INSTALL. The MDT category 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 are mandatory:

•

•

•

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

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

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

Note You can install a transformer in the device location. You can then install a second device and allocate it to the transformer. The same applies to pressure regulators and audio-frequency ripple control receivers (ARCRs). You use the equipment number to allocate transformers, pressure regulators or ARCRs to a device. Use one of the following attributes:

• WANDNRE: Transformer equipment number

• DRUCKNRE: Pressure regulator equipment number

• TRENRE: ARCR equipment number

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

Seite -39-


•

• •

With ZWNUMMERE (register number) you specify the register of the device to which the data refers.

With PERVERBR you maintain the period consumption of the register.

With ZWSTANDCE you enter the meter reading at device installation.

Note Some attributes of DEVICE_TECH_INSTALL and REG_TECH_INSTALL are dependent on the division or register category. If in doubt you can orient yourself on the Technical Installation transaction on the SAP Easy Access menu under Utilities Industry → Device Management → Installation.

- SERV_FREQ_SERV_LOC DEVICE_LOCATION contains the sub-category SERV_FREQ_SERV_LOC. You can use this MDT category to allocate a service frequency to a container on the container location (in the Waste Management component, the device location is called container location and the device 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 or changed using DEVICE_LOCATION. The DEVLOC node (device location- in this case container location), is always transferred by the automatic key assignment functionality.

SERV_FREQ_SERV_LOC is not underneath DEVICE_TECH_INSTALL. This means that you 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 must use a different parameter in the SERNR attribute (serial number- in this case container number)/equipment number for each container.

Example 1

•

•

•

•

•

You activate the DEVICE_LOCATION node and used the DEVLOC parameter for the DEVLOC attribute.

You activate the DEVICE_TECH_INSTALL twice and use the parameter names SERNR1 and SERNR2 for the SERNR attribute.

You activate the SERV_FREQ_SERV_LOC node twice and use the SERNR1 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 SERNR1 and SERNR2 parameters. Leave the DEVLOC parameter empty.

Result: a new container location is created. The two containers are technically installed. A service frequency is installed to each container.

Example 2

•

•

You activate the DEVICE_LOCATION node and used the DEVLOC parameter for the DEVLOC attribute.

You do not activate the DEVICE_TECH_INSTALL node.

Seite -40-


•

•

•

You activate the SERV_FREQ_SERV_LOC node and use the parameter name SERNR for the SERNR attribute. Automatic key assignment is used for the DEVLOC attribute.

You execute the MDT and transfer the key of an existing container location for the DEVLOC parameter. In the SERNR parameter, you transfer the key of a container that is already technically installed in the container location.

Result: The installed containers are allocated to a service frequency.

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

You can use the ENQUNR attribute (equipment number of the container) as an alternative to the 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 be allocated to the container. If you do not enter a value the date on which the container was technically installed on the container location is copied.

The STARTTIME, STOPTIME and TIMEFRAME attributes can only be used together. This means, if one of these attributes is allocated a value then so must the other two. This also applies to the SEASON_FROM and SEASON_TO attributes.

Depending on whether you create a weekly, monthly, daily or one-off service, several fields are mandatory. See the table below for more information (note, the entry X means the attribute has a value).

Attribute Weekly Monthly Daily One-Off

WEEKLY X

EWEEKDAY X X

MONTH_COUNT X

MONTHLY X

DAY_TYPE X X

1.7.9 POD_STAND_ALONE You can use POD_STAND_ALONE to maintain points of delivery at premise level. You use the 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 is changed.

• If you leave INT_UI initial, a new point of delivery is created and a new point of delivery key determined This new key can be transferred by key reference via the INT_UI attribute to the lower-level POINT_OF_DELIVERY node. You use POINT_OF_DELIVERY to allocate the point of delivery to a utility installation. If a premise has several nodes from the POINT_OF_DELIVERY category, the new point of delivery is allocated to several installations.

Seite -41-


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

1.7.10 PREMISE For 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 (initial data creation) or CONNOBJ (connection object). However, you can also use PREMISE independently to create or change a premise.

You can use the INSTALLATION sub-node to create one or more utility installations, or change them, albeit with restrictions. You can use the CONTRACT sub-node to create a new contract for each utility installation. You can use the CONTRACT sub-node to define the characteristics 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, with the MOVE_IN sub-node. This results in the following rules:

•

•

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

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

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

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 (the corresponding 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.

- MOVE_IN If you execute MOVE_IN as a sub-node of NEWCUSTPOD, the value of the contract account key from the CONTRACT_ACCOUNT sub-node is automatically allocated to the VKONT attribute. Otherwise you must transfer the contract account, for example as a parameter.

You use the EINZDAT attribute (move-in date) to define the move-in date of the contracts to the premise.

The EINZBELEG (as of IS-U Releases 4.64+, 4.71+, 4.72+) do not play a role in the execution of the MOVE_IN node. You cannot enter the key from a move-in document in this attribute in order to change an existing move-in document. The attribute only enables you to access the move-in document after you have run the master data template. To do this, you must select Parameter in the template for the attribute. After you have executed the function module ISU_PRODUCT_IMPLEMENT you can then get the move-in document number from the export table XY_NEW_KEYS_TAB.

In move-in Customizing you can determine whether the premise address is to become the new standard address for the business partner. In Customizing for SAP Utilities, select Customer Service → Process Execution → Move-In/Out → Move-In → Define Move-In Control Parameters at Document Level.

Seite -42-


As of IS-U Release 4.72, you can override these settings with the attribute COPY_PREMISE_ADDR when executing the node.

• If you set the COPY_PREMISE_ADDR attribute to the value ‘0’, the premise address is not adopted as the new standard address for the business partner, regardless of the settings in Customizing.

• If you set the COPY_PREMISE_ADDR attribute to the value ‘1’, the premise address is adopted as the new standard address for the business partner, regardless of the settings in Customizing.

• If you do not activate the COPY_PREMISE_ADDR attribute (Do Not Change), or set it to the value ‘ ‘, the move-in observes the specifications in Customizing.

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

• If you set the CREATE_WELC_LETTER to the value ‘0’, no welcome letter is generated.

• If you set the CREATE_WELC_LETTER to the value ‘1’, a welcome letter is generated.

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

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

• CTYPE Contact type

• ALTPARTNER Contact partner

• CTDATE Date

• CTTIME 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-in document.

In dialog, you create a move-in using transaction EC50E. On the initial screen you can find detailed information on the move-in functionality in the menu under Help → Application help. This documentation is also to a great extent applicable to automatic processing by the MDG. Familiarize yourself with this information before you begin.

Example: during a move-in into an installation with metering devices, meter reading results must be entered. You can adopt existing meter reading results as the meter reading results at move-in. The details are controlled by the Customizing settings. Also, read the section on meter reading data in the application help.

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

Seite -43-


•

•

•

•

•

•

•

•

• • •

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

If the budget billing cycle of the contract, or the portion belonging to the 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 each premise. 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 budget billing plan. Use the attributes as follows:

In the ANLAGE attribute (installation), you must specify the key of the installation for whose contract you want to create a budget billing plan. Since the MOVE_IN_BBP node is not a sub-node of INSTALLATION, you cannot use the Key Reference evaluation category. Instead, in the case of the INSTALLATION and MOVE_IN_BBP nodes, you respectively use the same parameter for the ANLAGE attribute.

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

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

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

If you perform a move-in with more than one contract, the Invoice contracts together control decides whether each contract has its own budget billing amount. A budget billing plan for all the contracts is created for contracts in which the control (see the GEMFAKT attribute in the CONTRACT node) contains the value 1 Contract must be invoiced jointly with other contracts

Contracts in which the value 2 Contract can be invoiced jointly with other contracts 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 at move-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 MOVEINDOC BOR object. The affected contracts are written to the event container as a table (to be precise, to the Contracts container element).

Seite -44-


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

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

•

•

•

•

• •

You execute the move-in with the MDG, without entering the meter reading 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 Reading → Basic Settings → Define Control Parameters for Meter Reading Data Processing and maintain an interval that defines the default value for the move-in. Based on this setting, the MDG checks whether the interval contains suitable meter reading results. If so, the results are automatically adopted as the meter reading results at move-in. For more information see the Create Move-In transaction (EC50E) in the menu under Help → Application help → Move-in → Meter reading data.

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

Use the attributes of MOVE_IN_MR as follows:

With EQUNR (equipment number) and ZWNUMMER (register number), you define the register for which you want to enter a meter reading result. You can use a value for the SERNR (device number) and MATNR (device category) attributes as an alternative to EQUINR. Note however, that you cannot use this alternative if the device info record has an ambiguous device number. We therefore recommend that you use EQUINR whenever possible.

In the ZWSTAND attribute, you specify the meter reading.

The other attributes are optional.

Seite -45-


1.7.11 INSTALLATION You 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 also use INSTALLATION as an autonomous MDT category.

Note You 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_HISTORY The mandatory INSTALLATION_HISTORY sub-node contains the historical data of the installation. When a new installation is created, the AB attribute (date, from which a time slice 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 been billed cannot be changed.

Normal Installation Facts You generate or change normal installation facts (installation facts that are not reference values) using the sub-nodes named after the operand categories INST_FACTS_ADISCABS,...,INST_FACTS_USERDEF.

You use the AB and BIS (date, to which a time slice is valid) attributes to define the time slice for which an installation fact is valid. If you want the fact to be permanently valid, set the BIS attribute to 31.12.9999. As of IS-U Release 4.71, an empty to-date is automatically interpreted as 12.31.9999. This is also the case in Release 4.6x if you import the correction for OSS note 581446.

You can activate the sub-nodes of the facts repeatedly. This enables you to:

•

• •

Create several facts, each with different operands but the same operand category

Create more than one time slice for one operand

Maintain various seasonal values for one operand (if you do not want a seasonal reference, set the either the initial value or the Do not change evaluation category in the SAISON attribute)

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

Example • The utility installation contains a fact for the FACTOR1 operand without a

seasonal reference for the period 1.1.2000 to 31.12.9999 and a fact for the FACTOR2 operand.

• In the template, activate the INST_FACTS_FACTOR node with the FACTOR1 operand without a seasonal reference with the time slice 1.7.2000 to 31.12.9999.

• After you have executed the template, the installation contains two time slices for the FACTOR1 operand: 1.1.2000 to 30.6.2000 with the old value and 1.7.2000 to 31.12.9999 with the new value from the MDT. The

Seite -46-


fact for the FACTOR2 operand remains unchanged.

Note

You cannot use the MDG to delete or chronologically restrict an installation fact.

Nodes for price operands also have the optional sub-nodes LPRICE_INST_ASSIGN, QPRICE_INST_ASSIGN and TPRICE_INST_ASSIGN. These nodes define an installation reference. This means that the key for the utility installation (attribute ANLAGE in the higher-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 can only be used in the installation facts of the affected installation. In this way you can ensure that a customer-specific price is not inadvertently used for the wrong contract. You can no longer delete or change the installation reference for a price. In connection to installation facts that are maintained using the master data generator, two indicators, which you can maintain when defining the operand, are very important.

• Product-Related Operand

• Contract-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 dialog

• For a move-out, the fact is automatically completed for the move-out date.

In the integration solution between SAP CRM and SAP IS-U you must check, for each fact node, whether the indicator is set for the corresponding operand. It should only be possible, in the 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, this fact is automatically deactivated for move-out. For the meaning during move-in, see the online documentation for the indicator. You should use this indicator for all facts that refer to a particular contract, such as individual prices.

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

•

•

•

•

•

Activate the QPRICE and QPRICE_HIST nodes. Use the data source type 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 an installation fact with the operand category QPRICE. For the PREIS attribute, use the same parameter name as in the QPRICE node. Use an operand in which the indicator Contract-Related Operand is selected.

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 number assignment 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 price is used for billing the current contract. You must, however, use a price operand from the

Seite -47-


billing scheme. The Contract-Relevant Operand indicator 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 of this installation.

The changes to customer-specific prices are a little confusing. This is because there is an interplay here between the time slices for utility installations, installation facts, contracts and prices. 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 create customer-specific prices, and to allocate these prices to a particular contract. Amongst others, you activate the following nodes and parameters:

Node category Attribute Parameter name

QPRICE PREIS (price key) PRICEKEY

QPRICE_HIST ABDATUM (from-date of price)

FROMDATE_PRICE

QPRICE_HIST PREISBTR (price amount) AMOUNT_PRICE

INSTALLATION_HISTORY AB (from-date of installation) FROMDATE_INST

INST_FACTS_QPRICE AB (from-date of fact) FROMDATE_FACTS

INST_FACTS_QPRICE PREIS (price key) PRICEKEY

MOVE_IN EINZDAT (move-in date) MOVE_IN_DATE

1st Step: Run master data generator

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

Node category Parameter name Value

QPRICE PRICEKEY -

QPRICE_HIST FROMDATE_PRICE 01.01.2003

QPRICE_HIST AMOUNT_PRICE 0.20

INSTALLATION_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:

Seite -48-


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 key 1000.

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

• A new contract with the key 3000 is created. Price amount 0.20 is used when billing this contract.

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


QPRICE PRICEKEY 1000


QPRICE_HIST AMOUNT_PRICE 0,21



INST_FACTS_QPRICE PRICEKEY 1000

MOVE_IN MOVE_IN_DATE -

Seite -49-


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 installation 2000.

• As of 04.01.2003 contract 3000 will be billed with the new price amount of 0.21.

3rd Step: Move-out (without master data generator)

You execute a move-out for contract 3000 for 09.30.2003.

Result:

Seite -50-



1000Fact


3000Contract

09.30.2003

1000/0.20

1000

• The price fact for installation 2000 is automatically limited during move-out. The

price itself remains unchanged. Prerequisite for this is that you use an operand in which the indicator Contract-Relevant Operand is selected.

• Contract 3000 is restricted to the move-out date.

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


QPRICE PRICEKEY -


QPRICE_HIST AMOUNT_PRICE 0.19



INST_FACTS_QPRICE PRICEKEY -

MOVE_IN MOVE_IN_DATE 10.01.2003

Seite -51-


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 price key 1005.

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

Reference Values You 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 reference values)

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 slices differs greatly from the processing of other installation facts.

The nodes named above constantly add new reference values.

Existing reference values are not changed.

Seite -52-


Example • An 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 fact to 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 then contains 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. insensitive

You can use the INST_FACTS_RVAL_OPM master data template category to add one or more operation types to a street light. You cannot change the operation types of existing street lights.

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 an ACRC to an existing reference value.

You can use the INST_FACTS_RVAL_SVF MDT category to allocate a service frequency to a new container reference value. You cannot make any changes. If you maintain certain attributes, certain other attributes become required entry fields. For more information, see the notes in SEV_FREQ_SERV_LOC.

- LPROF_INST_ASSIGN and LPROF_INST_FACTOR You 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 attribute LOGLPRELNO corresponds to this logical number. If you execute this node and leave the attribute empty, a new assignment is created. If you maintain the attribute with the value of a logical number, the affected assignment is changed.

The user does not generally know the logical number of the load profile assignment. They are not displayed in the online transaction. The LOGLPRELNO_BY_PROFROLE attribute (determine logical number of load profile assignment by role) makes it easier to make changes. If you maintain this attribute with the value ‘X’ the master generator proceeds as follows:

• It ignores entries for attribute LOGLPRELNO.

Seite -53-


• The master data generator determines which Profile Allocation Role is specified for the PROFROLE attribute.

• It checks whether an assignment using this role exists for the utility installation. If yes, then this assignment is changed. If not, the system creates a new assignment.

However, you can only set the LOGLPRELNO_BY_PROFROLE attribute if the role is used in no more than one allocation for each utility installation. Otherwise you receive an error message 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 utility installation. The master data generator then proceeds as follows:

• It ignores entries for attribute LOGLPRELNO.

• The master data generator determines that Determine Current No. of Profile Alloc. Via EDM Profile No. is specified for the PROFILE attribute.

• It checks whether an assignment with this profile exists for the utility installation. If this is the case, the assignment is changed. If not, the system creates a new assignment.

Example Two synthetic load profiles are allocated to one utility installation. One of the two assignments has changed historically:

Logical number of assignment

From To Profile Role

4711 01.01.2002 30.06.2002 10001000 A100

4711 01.07.2002 31.12.9999 20002000 A100

4712 01.07.2002 31.12.9999 20002000 B100

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

• You run the master data generator and maintain the attribute LOGLPRELNO with the value 4711. The LOGLPRELNO_BY_PROFROLE and LOGLPRELNO_BY_PROFIL attributes remain empty.

• You run the master data generator and set the attribute LOGLPRELNO_BY_PROFROLE to the value ‘X’ and the PROFROLE attribute to the value A100.

• You cannot set LOGLPRELNO_BY_PROFIL for this utility installation. 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, the assignment 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 is defined 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.

Seite -54-


Example: You run the master data generator with the following data for the aforementioned installation.

• LOPGLPRELNO (logical number of assignment) = 4711

• AB (from-date) = 03.01.2002

• BIS (to-date) = 05.31.2002

• PROFILE (profile) = 30003000

• PROFROLE (role) = A100

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

Logical number of assignment

From To Profile Role

4711 01.01.2002 06.30.2002 10001000 A100

4711 03.01.2002 05.31.2002 30003000 A100

4712 07.01.2002 12.31.9999 20002000 B100

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

DEVICE_BILL_INSTALL and REG_BILL_INSTALL INSTALLATION contains the DEVICE_BILL_INSTALL sub-node. This MDT category enables the billing-related installation of one or more devices in the utility installation. DEVICE_BILL_INSTALL only has limited change functionality. DEVICE_BILL_INSTALL can only work with existing devices. These devices can either be normal devices or device info records.

DEVICE_BILL_INSTALL contains attributes at device level. The following attributes are mandatory:

•

•

•

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

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

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

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

Seite -55-


• •

With PERVERBR you maintain the period consumption of the register.

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

Note Some attributes of DEVICE_BILL_INSTALL and REG_BILL_INSTALL are dependent on the division or register category. If in doubt you can orient yourself on the Billing-Related Device Installation under Utilities Industry → Device Management → Installation.

When you execute the node, the system first checks whether the device is allocated to the installation at the specified date. If the device has not yet been allocated, the billing-related device 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, only the rate data of the MDT is transferred. In this case, the DEVICE_BILL_INSTALL and REG_BILL_INSTALL master data template categories change the rates for the device and register data.

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

• TARIFART rate type

• KONDIGRE fact group

• GVERRECH pay clearing price

• PREISKLAE 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 the product-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 meter reading 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 info record, 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 technically install a normal device, you can use the KENNZIFF attribute to change the value of the code If you do not, the default value from the register group is retained.

Billing-related device installations using REG_BILL_INSTALL also use the KENNZIFF attribute. However, you cannot change the value of the code. The attribute is only used by the environment determination function. This function can use the code to determine the node to which the REG_BILL_INSTALL node belongs. This is especially important if you use devices that have more than one register.

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

Seite -56-


•

•

•

•

You create an MDT for customers that have a double-rate meter. You activate the DEVICE_INFO node and replicate the REGISTER_INFO node. 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 the above codes are created and installed. The environment determination function and the codes in the REG_BILL_INSTALL node have no role.

You now execute the same MDT for an existing installation in which a double-rate meter has already been installed. The rate data of the MDT is to be copied for the registers. This is made possible by the environment determination function, and you do not have to explicitly specify the device number and register number. The environment determination function compares the codes in the REG_BILL_INSTALL nodes with the values of the registers and thereby creates the link.

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

Example

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

• Activate twice the node for the billing-related installation of a register. The first node installs a register with the rate data for an on-peak register. The second node installs a 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 the DEF_ZWNUMMER attribute, and enter the value 001.

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

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

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

Seite -57-


- LPROF_REG_ASSIGN You can use this sub-node for REG_BILL_INSTALL to allocate a load profile to an interval meter. 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 attribute LOGLPRELNO corresponds to this sequence number. If you execute this node and leave the attribute empty, a new assignment is created. If you maintain the attribute with the value of a logical number, the affected assignment is changed.

The user does not generally know the sequence number of the load profile assignment. They are not displayed in the online transaction. The following two attributes make it easier to make changes:

• ROLENO_BY_PROFROLE Determine sequence number of profile allocation by role

• ROLENO_BY_PROFILE Determine sequence number of profile allocation by EDM profile number.

The meaning of these attributes corresponds to that of LOGLPRELNO_BY_PROFROLE and LOGLPRELNO_BY_PROFILE for the attribute LOGLPRELNO. See the explanation and examples 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 DATEFROM attribute (from-date). The DATETO attribute (to-date) is optional. If you do not maintain this attribute, the assignment is created without a chronological restriction. If required you can also use the TIMEFROM and TIMETO attributes to predefine the time at which the assignment is to start and end.

In the case of changes, the assignment is changed from the time belonging to the DATEFROM and TIMEFROM attributes. The system does not change periods that lie before this time. The period after this time is completely defined by the specifications of the master data generator. If the DATETO attribute (to-date) is maintained, the assignment is limited to this to-date.

- POINT_OF_DELIVERY You can use the optional POINT_OF_DELIVERY sub-node to create or change a point of delivery.

• If you use POINT_OF_DELIVERY in the NEWCUSTPOD, CRMPARTNERTECH or CRMNEWCONTRACT master data template categories, the point of delivery is created by the higher-level node POD_STAND_ALONE. POINT_OF_DELIVERY is only used to 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_HISTORY node. When you change an installation, you use this attribute to determine the date from which the change is valid.

- CONTRACT You 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 in combination with the MOVE_IN node. You can only create contracts in combination with MOVE_IN. Without MOVE_IN, you can only change existing contracts.

Seite -58-


To change an existing contract, you must enter the key of the contract to be changed in the VERTRAG attribute. If you want to create a contract, the VERTRAG attribute must remain empty. As of Release 4.64+, 4.71 and 4.72 you can, after you have run the ISU_PRODUCT_IMPLEMENT function module, get the key for the new contract from the export table XY_NEW_KEYS_TAB. A prerequisite is that you select the data source type Parameter for the VERTRAG attribute.

1.7.12 BCONTACT You can use the optional BCONTACT sub-node to create a customer contact. You cannot use BCTONTACT to change existing customer contacts.

Provided a business partner can be uniquely identified in the MDT; the business partner reference is transferred to the PARTNER attribute. You must specify a contact configuration in order to create a customer contact. If you leave the CTDATE and CTTIME attributes empty, 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 object role, 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 this attribute contains the default value X and the other attributes are maintained as follows:

• • •

OBJECTROLE: PRODUCTLOG

OBJECTTYPE: ISUPRODLOG

OBJECTKEY: Blank character constant

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

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

• BP_IND_SECTOR

• LPRICE, LPRICE_HIST, LPRICE_INST_ASSIGN

• QPRICE, QPRICE_HIST, QPRICE_INST_ASSIGN

• TPRICE, TPRICE_HIST, TPRICE_INST_ASSIGN

• LPROF_INST_ASSIGN, LPROF_INST_FACTOR, LPROF_REG_ASSIGN

• CRMCONNOBJ_ALONECRMOUTLCONTRACTCRM_POD_INST

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

• BP_TAXNUM, BP_COPY_PREM_ADDR

• MOVE_IN_BPCONTACT

2 Master Data Templates in Release 4.63 In comparison with Release 4.64 MDT functionality, the following restrictions apply to Release 4.63:

Seite -59-


Internal number assignment is not possible in device info records. Serial numbers cannot be assigned repeatedly.

The following MDT categories are not yet available:

• MOVE_IN_MR

• INST_FACTS_RVAL_AREA

• SERV_FREQ_SERV_LOG

3 Master Data Templates in Release 4.62 In comparison with Release 4.63 MDT functionality, the following restrictions apply to Release 4.62:

The following MDT categories are not yet available:

• • • • • • • • • • • •

• CRMCONNOBJ

• CRMNEWCONTRACT

• CRMPOD

• CRMPARTNERTECH

• CRMPREMISE

• CRMTECHCONNOBJ

• CRMTECHOBJ

• INST_FACTS_RVAL_SRV

• MOVE_IN_BBP

• NBSERVICEOPAREA

• NBSERVICEPROVRELMETH

• NEWCUSTPOD• POD_STAND_ALONE

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

Caution

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

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

• • • •

BCONTACT

BCONTACT_NOTICE

BCONTACT_OBJECTS

DEVICE_BILL_INSTALL

Seite -60-


Seite -61-

• • • • • • • • • • • • • •

DEVICE_INFO

DEVICE_LOCATION

DEVICE_TECH_INSTALL

INST_FACTS_RATETYPE

INST_FACTS_RVALLIGHT

INST_FACTS_RVAL_CONT

INST_FACTS_RVAL_HEAT

INST_FACTS_RVAL_OPM

INST_FACTS_RVAL_STD

INST_FACTS_RVAL_TRE

POINT_OF_DELIVERY

REGISTER_INFO

REG_BILL_INSTALL

REG_TECH_INSTALL

Test Master Data Templates In Release 4.62 you can use the maintenance transaction to test MDTs. This functionality is not available in Release 4.61.

Sap Isu Master Data Template

Documents

Transcript of Sap Isu Master Data Template