Cookbook
IS-U Master Data Templates
in Release 4.71
©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.
Icons
Icon Meaning Caution
Example Note
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
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.
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.
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.
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-U master data Template ID Parameter Master data template Master data temp. cat. Master data generator Scripts Object Methods Work-flow Executing program
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?
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
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.
•
•
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:
•
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 categoryParameter. 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.
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
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.
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.
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.
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
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.
•
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
•
Grey: Parameter not yet assigned. NoteFor 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.
•
•
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:
•
•
•
•
•
•
•
•
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:
•
•
•
•
•
•
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.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
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:
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.
- 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 DevicesPermitted 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-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
•
•
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:
Node Attribute Data Source Value
DEVICE_INFO SERNR Do not change
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):
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:
DEVICE_INFO SERNR Parameter SERNR1
DEVICE_INFO MATNR Constant 1000
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:
•
•
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:
•
•
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:
Node Attribute Data Source Value
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:Node Attribute Data Source Value
REGISTER_INFO ZWNUMMER Constant 003
REGISTER_INFO DO_NOT_USE Constant X
•
You activate the REGISTER_INFO node with the following values:Node Attribute Data Source Value
REGISTER_INFO ZWNUMMER Constant 004
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.•
•
•
•
•
•
•
•
•
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.
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
