Capítulo 2: Marco Referencial
2.2. Marco teórico
2.2.2. Manual de procedimiento de operaciones
Business Example
Your company's new CD product is a huge success. To help manage all of the new suppliers, a new master data management administrator has been hired. The administrator starts on Monday and you have been asked to verify that the new user has been assigned the appropriate Master Data Governance roles and authorizations.
In this exercise, when values include ##, replace the characters with the number that your instructor assigned to you.
Verify a Role Assignment
1. Verify the authorizations contained within the role SAP_MDGS_REQ.
a) On the SAP Easy Access - User Menu screen, in the Command field, enter SU01.
b) Choose Enter.
c) On the User Maintenance: Initial Screen, in the User field, enter your user ID.
d) Choose Display.
e) On the Display Users screen, select the Roles tab.
f) In the Role Assignments table, double-click SAP_MDGS_REQ.
g) On the Display Roles screen, choose the Authorizations tab.
h) Choose Display Authorization Data.
i) In the Information dialog box, choose Enter.
j) On the Display Role: Authorizations screen, go to SAP_MDGC_REQ → SAP Master Data Governance → Type of Change Request → Type of Change Request.
Note:
This role is not restricted to any supplier change request type.
k) Choose Back to return to the SAP Easy Access - User Menu screen.
High-Level Business Workflow Components
Figure 47: High-Level Business Workflow Components
The integrated inbox lets you view and administer work items and supports all mail functions of SAP Workplace.
The System Work Item Manager processes workflow activities, including deadline monitoring.
When workflow activities include methods that run in the background, the System Work Item Manager initiates the background processes.
Single Processing of Supplier and Customer Records
Figure 48: Processing of Suppliers - Workflow Templates
Lesson: Configuring Master Data Governance Processes and the User Interface
For MDG Supplier and Customer domains, SAP provides a set of predefined workflow templates for the most common record processing scenarios.
This section describes each of these workflow templates with the corresponding dialog step numbers. Note that these step numbers are not in numerical order nor do they indicate a sequence, but instead describe the agent assignment.
The following predefined workflow templates apply to the Supplier domain:
● WS54300005: Create Supplier
- Step 1: Approval (decision)
- Step 4: Revision after Rejection
- Step 5: Data Maintenance (subworkflow)
- Step 6: Approval (subworkflow)
- Step 7: Activation (decision)
● WS54300007: Process/Change Supplier
- Step 1: Approval (decision)
- Step 4: Activation (decision)
- Step 5: Revision after Rejection
● WS60800059: Block/Unblock Supplier
- Step 1: Approval (decision)
- Step 2: Activation (decision)
- Step 3: Revision after Rejection
● WS60800068: Mark Supplier for Deletion
- Step 1: Approval (decision)
- Step 2: Activation (decision)
- Step 3: Revision after Rejection
● WS60800095: Mass Approval (BP Hierarchies, & BP Mass Maintenance)
- Step 1: Processing
- Step 2: Approval (decision)
- Step 3: Revision after Rejection
- Step 4: Revision after Rejection
- Step 5: Activation (decision)
● WS72100006: BP Initial Load
- Step 1: Processing
- Step 2: Approval (decision)
- Step 3: Revision after Rejection
- Step 4: Revision after Rejection
- Step 5: Activation (decision)
Figure 49: Processing of Customers - Workflow Templates
The following predefined workflow templates apply to the Customer domain:
● WS54300003: Process Single Customer (Create, Change, Block/Unblock, & Mark For Deletion)
- Step 1: Approval (decision)
- Step 2: Activation (decision)
- Step 3: Revision after Rejection
● WS46000023: Local Maintenance: Create Customer (additional steps for duplicate processing)
- Step 1: Maintenance of Duplicate Entries
- Step 2: Approval (decision)
- Step 3: Revision after Rejection
- Step 4: Activation (decision)
- Step 5: Address Rework/Review
● WS46000027: Local Maintenance: Process Customer (additional steps for duplicate processing)
- Step 1: Approval (decision)
Lesson: Configuring Master Data Governance Processes and the User Interface
- Step 2: Revision after Rejection
- Step 3: Activation (decision)
- Step 4: Address Revision after Validation
Processor Assignment to a Workflow Template Step
Figure 50: Assign Processor to Workflow Template Step Number
When defining a Change Request Type, a workflow template is assigned to determine how that change request is processed.
Predefined workflow templates include a set of interactive steps that require user input. Each step is identified by a number that is unique in the specific workflow template.
The system uses this unique number to assign an agent — a single or a group of processors — to the specific workflow template step.
The following types of agents exist in the system:
● C—Job
● O—Organization unit
● S—Position
● US—User ID
The first three agents are maintained in the organizational structure. The user ID agent is maintained in the user master.
Enhanced Financial Workflow Templates
Figure 51: Enhanced MDG Financial Workflow Template
The advanced financial workflow template WS75700043 allows for Entity Type-specific processors. An enhanced financial workflow template is only available for Change Request Types with the flag Objects Required. This workflow template is similar to the basic workflow template but includes a feature to assign separate processors for each entity.
Supplier Agent Determination
For change request types and their workflow template steps, assign the relevant agents.
Agents can refer to a single user or a complete organization unit.
Company code and the purchasing organization can be used to determine agents in the standard delivered Supplier workflow templates.
The BAdI MDG_BS_SUPPL_WF_AGENT_ERP is used to switch between BRFplus agent determination and the original table-driven method.
Supplier Agent Determination Filter
Table 6: Supplier Agent Determination Entries
Type Step CoCode Purch. Org. Flag
Central
SUPPL1P1 05 1000 — — US BRF_CC10
00
SUPPL1P1 05 — 1000 — US BRF_PO00
02
SUPPL1P1 06 — — — O 50000050
In addition to assigning agents to step numbers in pre-defined workflow templates, SAP delivers an improved method to assign agents for Suppliers using BRFplus. In addition to the step number, company code and purchasing organization IDs can be used for agent
determination. Switching between the original table-driven method and the BRFplus method is done in with object MDG_BS_BP_WORKFLOW_SWITCH.
Lesson: Configuring Master Data Governance Processes and the User Interface
Master Data Governance Workflow Template
Figure 52: Master Data Governance Workflow Template
Master Data Governance allows flexibility in the SAP Business Workflow. The following types of business workflow templates are available:
● Standard business workflow templates, which include predefined, fixed content
● Rule-based workflow templates, which include default content delivered for Material The rule-based workflow template is flexible and can handle any process in any MDG domain.
Some of the predefined workflow templates are generic enough to be used with any object.
However, unlike the rule-based template, the processing steps of the predefined workflow templates are fixed and cannot be changed. Changing a fixed, predefined workflow template involves making a copy of the original template and then changing to copy. Each change request type can be assigned a single workflow template and both are linked in the change request type definition table.
The Material workflow template uses a two-step approval process for governance purposes.
The following process ensures compliance with the two-step rule:
1. The business user requests creation of a material or a change to material data and submits a change request.
2. The master data expert is notified through the Worklist that the new change request is created. The expert reviews the data, which can be changed or enhanced, and then approves the request.
If the expert wants to send back the request for clarification, an additional process for revision and resubmission is included in the standard workflow template. This process includes the following steps:
1. The business user requests the creation of a material or the change of material data and submits the change request.
2. The master data expert is notified through the worklist that the new change request is created. The expert reviews the data, which can be changed or enhanced, and sends the review back to the business user for revision and clarification.
3. The business user can cancel the request or adjust the data and then resubmit the request.
4. The master data expert reviews and revises the request. If the data is complete and correct, the change request is approved, otherwise it is sent back to the user for revision.
Workflow Template Assigned to Change Request Types
A default set of change request types is delivered with Master Data Governance for Material and activated using the Business Configuration Set (BC-Set). Each change request type is assigned to one of the predefined Business Activities. You can use the default change request types or create your own.
The connection to the workflow template determines the main processing logic of the change request. For Material, the standard rule-based workflow template WS60800068 is delivered.
The following Material change request types are provided:
● MAT01—Create material
● MAT02—Change material
● MAT06—Mark material for deletion
● MAT0A—Process multiple materials
● MAT0B—Import material
The actual processing logic of a rule-based workflow template is defined using a predefined set of BRFplus applications where steps and agents are determined dynamically.
Lesson: Configuring Master Data Governance Processes and the User Interface
Generic Workflow Template
Figure 53: Rule-Based Workflow Template
SAP provides the standard rule-based workflow template WS60800068. This template is a dynamic solution that can be easily customized for each MDG process.
The standard SAP business workflow template is enhanced with a rule-based engine. The rule-based workflow template is controlled through a special set of BRFplus applications that have the same signature and contain the same set of decision tables. Each change request type has its own BRFplus application with its own copy of those decision tables. Populating those tables is a customization task that occurs during implementation projects. You can use the sample customization tasks as a template for further enhancements.
The following decision tables are maintained:
● Next-step table—Identifies the next step in the process.
● Dialog agent table—Identifies the processors of an interactive dialog step.
● Background-step table—Identifies the type, or processing pattern, of a background step.
The rule-based workflow template has a main loop that checks whether a next step exists.
Inside the loop, the first task is to read the next step and the assigned agents. Next, the main branch of the workflow is a CASE or IF statement in which processing patterns are evaluated.
Based on the pattern that is identified in the corresponding decision table, workflow instance control is routed through a single specific branch in each iteration. Finally, the condition to exit the loop is triggered, which results in completion of the workflow instance.
The CASE statement contains the following options for the processing pattern:
Table 7: Background Step Table
Step Type Step Type Name Processing Pattern
01 UI Dialog Determines the interactive
dialog step in the
corresponding decision table
02 Call Synch. Method Calls the specified method
03 Call Sub-Workflow Calls the specified workflow
template
04 Call Data Replication Replicates data at an exact
point in the process without waiting for the replication schedule
05 Activation (do not bypass
snapshot)
Activates the data, considering the snapshot that was taken when a change request was initially created
06 Activation (bypass snapshot) Activates the data regardless of the snapshot date
07 Validate Change Request Runs validations in the
background
08 Roll Back Change Request Rolls back any changes
98 Error Issues an error in the process
99 Complete (Sub)Workflow Marks change requests as
completed
Each process step customized in the BRFplus application decision table has one these processing patterns. Consider the following example:
Table 8: Next-Step Table
Process Step Description Step Type
Step 1 Interactive processing Type 01
Step 2 Validation Type 07
Step 3 Interactive final approval step Type 01
Step 4 Activation Type 06
Step 5 Completion Type 99
Lesson: Configuring Master Data Governance Processes and the User Interface
Default Workflow in Rule-Based and Classic Templates
Figure 54: Default Workflow in Rule-Based and Classic Templates
The figure Default Workflow in Rule-Based and Classic Templates illustrates a standard two-step rule process in the rule-based workflow template using BRFplus. The following symbols show the steps, status, and actions that are represented in the BRFplus decision tables:
● Chevrons—The steps, whether manual or automated steps
● Dark rectangles—The statuses, visible in worklists and workflow inboxes
● Black arrows and text—The actions, either triggered by the user or automated
A status is assigned to the change request for each step. The actions determine the progress from one step to the next. The following steps and actions are used in the figure Default Workflow in Rule-Based and Classic Templates:
● Step 00: The business user initiates a change request by starting to create or change a material. As long as the data is saved in draft mode, no workflow is triggered. Technically, the change request is kept in cluster tables for temporary storage.
● Action Submit: When the change request is submitted, the workflow is triggered and the data transferred to the staging area. If the workflow is not started, the status changes to 02: Changes to be executed.
● Step 90: The master data expert verifies and enhances the data and performs the final check.
● Action 09 Activate: The expert triggers the activation of the data. System tasks, which are not shown in the figure, ensure that the data is validated before physical activation.
Inconsistencies, potential duplicates, and ungoverned changes in the backend are detected and communicated to the expert through messages and the error log.
● Step 91: An automated workflow task activates the data in the active area. If this operation is successful, the status 05: Final check approved is set. Actions in the background
complete the workflow.
● Step 99: The workflow is approved and complete. The change request is no longer active.
The revision steps are triggered and performed as shown in the figure Default Workflow in Rule-Based and Classic Templates. In the default workflow setting, only the original requestor can withdraw a change request.
Generic Workflow Template Controlled by Rules
Figure 55: Generic Workflow Template Controlled by Rules
The Material workflow template includes a simple, single-approver, rule-based workflow template configuration, which can be enhanced during implementation. The same process logic is configured for all MDG Material processes such as Create, Process, and Mark for Deletion.
Workflow Template Step Types and Actions
Every dialog step, which is an interactive step, in the rule-based workflow template configuration requires an assigned type. Examples of these dialogs steps include Check Change Request and Activate Change Request. A step type signifies which actions can be taken for a step by providing a set of buttons that appear in the UI for each step in the change request. An action such as Approve or Send for Revision indicates that a decision should be made by the user. MDG provides a predefined set of actions and step types. You can add new actions and step types in the following tables:
● Actions: Maintenance View V_USMD220C
● Step Types: Maintenance View V_USMD230C
● Assignment of Actions to Step Types: Maintenance View V_USMD2301
Lesson: Configuring Master Data Governance Processes and the User Interface
Enhanced Change Requests
Existing single-approver, rule-based workflow template configurations can optionally be enhanced by adding an interactive expert review step just before the approver step. An enhanced change request workflow template might consist of the following steps:
1. The standard, delivered, rule-based workflow configuration sends the change request from the requestor to the approver.
2. The change request goes from the requestor to the expert.
3. If the expert agrees, the change request goes to the approver once the expert agrees.
4. If the expert disagrees, the change request goes to back to the requestor.
Extensibility Checklists
One major focus of MDG is reuse and extensibility. It is common for customers to make extensions to the standard SAP master data models. Many companies have specific master data creation and change processes. MDG offers the flexibility and extensibility features to adapt the standard model to their needs. This flexibility allows customers to make extensions and still benefit from MDG’s out-of-the-box capabilities.
The following checklist includes the high-level steps required to extend the standard MDG data model and process:
● Data Model
- Create a data model
- Create entity types
- Create relationships
- Save and activate the data model
● UI Configuration
- Create a new UI configuration
- Configure the UIBB
- Set the attributes of the fields
● Process Modeling
- Create business activity
- Create a change request type
- Define the workflow template
- Set up the organizational structure
- Assign processors
- Create a role
● Test the Process
- Create a change request
- Process the change request
- Approve the change request
How to Change a Standard Workflow Template User Interface
For the demonstration steps and data, see the exercise Change a Standard Workflow User Interface.
Lesson: Configuring Master Data Governance Processes and the User Interface