SAP How-To Guide Master Data Governance for Material How To... Master Data Governance for Material: Check and Derivation Rules - PDF

Please download to get full document.

View again

of 94
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Funny & Jokes

Published:

Views: 278 | Pages: 94

Extension: PDF | Download: 0

Share
Related documents
Description
SAP How-To Guide Master Data Governance for Material How To... Master Data Governance for Material: Check and Derivation Rules Applicable Releases: EhP5, EhP6, MDG6.1, MDG7.0 Version 2.0 December 2014
Transcript
SAP How-To Guide Master Data Governance for Material How To... Master Data Governance for Material: Check and Derivation Rules Applicable Releases: EhP5, EhP6, MDG6.1, MDG7.0 Version 2.0 December 2014 Copyright 2014 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, Outlook, and PowerPoint 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, i5/os, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States 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, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C 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. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mysap, mysap.com, xapps, xapp, SAP NetWeaver, 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. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ( SAP Group ) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. SAP NetWeaver How-to Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, clarification or support, please refer to SAP Consulting. Any software coding and/or code lines / strings ( Code ) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent. Disclaimer Some components of this product are based on Java. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java Source Code delivered with this product is only to be used by SAP s Support Services and may not be modified or altered in any way. Document History Document Version Description 1.00 First official release of this guide 1.20 Rule for Backend Check for Net weight 1.30 Additional notes, General Implementation 1.40 EhP6: BAdI USMD_RULE_SERVICE_CROSS_ET Chapter New Chapter: Derivation with BAdI USMD_RULE_SERVICE_CROSS_ET 1.60 New function in MDG6.1 (see Chapter 3.4 and also Note ) 1.70 Chapter 4.4, 5.2 and Small corrections in chapter 5.1 and New Chapter: Cross Entity Read Access 2.00 Small corrections Typographic Conventions Type Style Example Text Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation Icons Icon Description Caution Note or Important Example Recommendation or Tip Example text Example text Example text Example text EXAMPLE TEXT Emphasized words or phrases in body text, graphic titles, and table titles File and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. User entry texts. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER. Table of Contents 1. Business Scenario Prerequisites Definition and Overview Definition Overview Checks and Derivations Checks Model driven checks Code lists Cardinality check Format check Required fields Re-use of existing check logic in ECC Customizing OMT Code list Business checks (Material API) Required fields as defined in material master customizing (T130F) and hardcoded (Material API) Custom Checks Checks using BRF+/BAdI USMD_RULE_SERVICE Customizing CR Type for Check messages Customizing setting: Issue Error as Warnings Customizing setting: Standard Configure Properties of Change Request Step Checks with BRF Example for CHECK_MATERIAL Simple Checks Example for CHECK_MEAN_GTIN Simple Checks Example for CHECK_UNITOFMSR Simple Checks Rule to compare Net and Gross weight for Base Unit of Measure Example for CHECK_MARCBASIC Warning, if Serial Number Profile is changed Derivations Custom derivations Derivation using BRF+/ BAdI USMD_RULE_SERVICE EhP6: Derivation using BAdI USMD_RULE_SERVICE_CROSS_ET Comparison of Derivations Change Request Enrichment BADI (MDG_BS_MAT_API_ENRICH_BADI) SMT-Mapping Staging Active Area Derivations with BRF 7.1 Cross-Entity Rules Defaulting of values Example for DERIVE_MATERIAL Execution time Simple Rules Example: Rules with Expression Example: Decision Table with multiple results Example for DERIVE_MARCMRPFC Default the Period Indicator to M Example for DERIVE_MARCMRPSP Default the Procurement Type Example: Using variables in Derivation Rules (like Workflow step) Set the values for the variables Create BRF+ Ruleset Create BRF+ Function EhP5 screenshots of the process Cross-Entity Read Access for Derivation Example: Change the MRP Type Depending on the Plant-Specific Material Status Prerequisite: Create Data Object Prerequisite: Create Post-Exit Prerequisite: Create Z-Class Create Derivation for MARCMRPPP Add method to the Post-Exit Test the BRFplus Rule Cross-Entity Derivation with BAdI USMD_RULE_SERVICE_CROSS_ET Technical environment BRF+ Landscape and Rule Maintenance Use case Example for Application Exit GET_CHANGEABILITY... 86 1. Business Scenario SAP Master Data Governance for Material (MDG-M) provides business processes to find, create, change, and mark material master data for deletion. It supports the governance of material master data in a central hub and the distribution to connected operational and business intelligence systems. The processes are workflow-driven and can include several approval and revision phases, and the collaboration of all users participating in the master data maintenance. To support these processes, check and derivation rules can be created for the MM data model. Checks ensure that the master data is consistent. You can use derivations to calculate values for attributes from other resolved attributes, thereby simplifying data entry. This How-To Guide gives an overview of the checks used in MDG-M and gives examples for Checks and Derivations built in BRF+. 2. Prerequisites Check if the following SAP Notes are required and implemented in the system: Unexpected mandatory fields after model extension Field selection control apparently not working Integrating cust.-specific fields in matl master BRF+ and BAdI derivations are not performed After model extension data disappears from UI Call of derivations only at end of write loop Incorrect required field check for execution via BAdI BRF plus documentation Online help 9/content.htm?frameset=/EN/00/da13e29b4e4fb4ace5990f212a05da/frameset.htm SDN Link to Business Rule Framework plus: f283-2b10-6d9f-b10f3c28c3a0 Link to Business Rules Management: Blog of BRF plus: BRF plus Application Exits dbb7-cb1f0a21496e 3. Definition and Overview 3.1 Definition Checks raise messages. Message with severity info, warning, error and abort are possible. Derivations calculate values for attributes and can also raise messages. Only messages with severity info are possible. 3.2 Overview Checks and Derivations Model driven checks o Code list check o Cardinality check o Format check o Required fields Re-use of existing check logic in ECC o Check messages configured in OMT4 o Code lists o Business checks (Material API) o Required fields as defined in material master customizing (T130F) and hardcoded (Material API) Custom checks (modeled and programmed) o Rules from the Business Rules Framework (BRFplus) o Coded rules using the BAdI USMD_RULE_SERVICE Custom derivations (modeled and programmed) o Rules from the Business Rules Framework (BRFplus) o Coded rules using BAdI USMD_RULE_SERVICE o Coded rules using BAdI USMD_RULE_SERVICE_CROSS_ET o Coded enrichments using the BAdI MDG_BS_MAT_API_ENRICH_BADI o Derivation with SMT-Mapping Checks are usually carried out at Check, Run Validation, Save, and Activate while derivations are carried out each roundtrip. In addition, input errors found by basic technical checks (like for Units of Measure, Dates, and Currencies) are always executed after the next round trip and issued as errors. 4. Checks 4.1 Model driven checks Code lists The considered Code list for the check comes from the Fixed Values or Value Range Table which is assigned to the domain of the data element. In the customizing for the MM data model you can use the No Existence Check to deactivate the standard existence check for the value of the attribute. Path: Master Data Governance - General Settings - Data Modeling - Edit Data Model (VC_USMD001) Cardinality check A field is mandatory if the referencing relationship has cardinality 1: Format check Data element is used for format check Required fields Attributes can be defined as required fields. 4.2 Re-use of existing check logic in ECC Customizing OMT4 Only messages with severity E from the material API are shown in MDG. These can be messages for the required fields or additional messages defined in the customizing OMT4. (See Customizing, under Logistics - General - Material Master - Basic Settings - Define Attributes of System Messages). With the customizing of the change request type you can decide if these E messages are shown as errors or as warning messages during the governance processes. But at activation there is no conversion of the messages. New function in MDG6.1 (see also Note , Chapter Message configuration in OMT4): Transaction OMT4 provides configuration for message severity. Messages can be raised as errors, warnings, or not at all. MDG-M only supports the severity configuration for a subset of these messages. If a message from this subset is configured as a warning, it is also shown as warning in MDG- M If a message not in this subset is configured as a warning, it is not shown in MDG-M Messages configured as errors are always shown as errors. Supported subset: M3, configuration for messages 132, 159, 285, 347, and 348 is supported MM, configuration for messages 189, 312, and 657 is supported MH and WE, configuration for messages is not supported Code list The Material API checks the Fixed Values or Value Range Tables which are assigned to the domain of the data elements in the material master tables Business checks (Material API) The Material API is called at Check, Run Validation, Save, and Activate Check and Save only check the changed material Run Validation checks the complete change request In Single Item Maintenance UI and Mass Maintenance UI, File import, etc. Some of the settings of the Material Master Customizing are considered in MDG through the Material API. All settings from the section Basic Settings are considered. For example, the output format of the material number and the material types. All settings from the section Settings for Key Fields are considered. For example the definition of material groups and basic material and the settings for EAN s. In addition, UserExit (SMOD) MGA00001 and BADI_MATERIAL_CHECK are considered in MDG-M Required fields as defined in material master customizing (T130F) and hardcoded (Material API) The field properties for required fields in the Material Master Customizing are considered in MDG. The section Field Selection is considered. Changes affect the field s properties in MDG-M. There, you define if a field is required (table T130F). The field properties are determined by the field selection group. For the specification of the properties of a field selection group, there are several criteria. These are called field selection references. Six criteria (field selection references) are relevant for the definition of the field selection attributes (see consulting note ). The six field selections which are relevant for MDG_M are: Industry sector, Material type, transaction MM01 and field selection control KB. Also considered are SAP1 and SAP2, but must not be changed by customer. Also, BADI_MAT_F_SPEC_SEL is considered in MDG-M. 4.3 Custom Checks Checks using BRF+/BAdI USMD_RULE_SERVICE Check Entities from the BRF+ Rules and the Check BAdI are called at Check, Run Validation, Save, and Activate. Check Change Request from the Check BADI and the BRF+ Rules is called at Run Validation and Activate. Check/Save only check the changed Material Run Validation checks the complete Change Request Valid for Single Item Maintenance UI and Mass Maintenance UI, File upload, Data import 4.4 Customizing CR Type for Check messages Only messages with type error from the backend Material API are shown in MDG-M. Additional messages for checks can be created with BRF+ or with a BADI. These can be shown as abort, errors, warnings, or info. Within the customizing of the change request type you can decide if these are shown as errors or as warning messages. Note: Input errors found by basic technical checks (like for Units of Measure, Dates, and Currencies) are always issued as Errors Customizing setting: Issue Error as Warnings Messages from Derives are allows converted into info messages. 4.4.2 Customizing setting: Standard Messages from Derives are allows converted into info messages Configure Properties of Change Request Step In this Customizing activity, you determine settings for the execution of a change request step for a change request type. Enrichment Spots and Checks per Change Request Step View In this view, you can complete the following actions for a change request step: Specify which enrichment spots and checks are relevant. View the execution sequence for enrichment spots and checks. Control the display of messages by specifying a message output. For example, you can ensure some messages display only as warnings. Determine whether a check is always executed or only executed when changes occur. Entity Types per Change Request Step View and Attributes per Change Request Step View You can complete the following actions for a change request step: Specify which fields are relevant, and which relevant fields are required, by setting field properties. For example, you can make a required field optional. Reduce the number of checks applied to fields by specifying a Check Logic for an entity type. You can only define properties for entity types, attributes, or relationships that are governed. You can apply this setting in Customizing for Master Data Governance under General Settings - Process Modeling - Define Governance Scope. For the field properties topic please see also the How To Guide for the UI. You can find it here: See chapter for Field Properties. 5. Checks with BRF+ Path: MDGIMG - General Settings - Data Quality and Search - Define Validation and Derivation Rules. In this Customizing activity you define the validations and derivations for a data model. This activity calls the Web Dynpro application Definition of Rules for Validations and Derivations (USMD_RULE). You can define validation and derivation rules for the data model MM. The system automatically generates the data objects used for the rule for the selected data model. For a precise description of the procedure, choose Help on the initial screen of this Web Dynpro application Important There is a Naming Convention for Trigger function nodes in the catalog structure. The naming convention for check trigger function nodes of a catalog structure is CHECK_ name of entity type , for example, CHECK_MATERIAL The naming convention for derivation trigger function nodes of a catalog structure is DERIVE_ name of entity type , for example, DERIVE_MATERIAL Important If you update/change the data model MM, the data objects are updated. But if you used a data object already in a function as a signature, it is not automatically updated. Please see SAP Note for how to proceed. 5.1 Example for CHECK_MATERIAL 5.1.1 Simple Checks You can also use Message with message class USMD5 a message number 000, where you can specify variables. 5.2 Example for CHECK_MEAN_GTIN Simple Checks 5.3 Example for CHECK_UNITOFMSR Simple Checks Rule to compare Net and Gross weight for Base Unit of Measure There is a check in the backend transactions for Material which compares the Net and Gross weight for the Base Unit of Measure. If the net weight is greater than the gross weight, the message The net weight is greater than the gross weight is raised (see TA SE91 Message class M3 and message 176). The backend check does not show up in MDG, because message M3 176 is not in the supported subset (see chapter Customizing OMT4). Therefore this message is only shown in MDG if the severity is an error message. Solution: You can create a BRF+ rule if the check is also necessary in MDG. 5.4 Example for CHECK_MARCBASIC Warning, if Serial Number Profile is changed Scenario: There should be a warning message when you change the Serial Number Profile (SERNP) for a material which
Recommended
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks