Title Link

4. Keywords

5. Introduction / Overview
5.1 Current State
There is no current solution available for Sites to easily manage the
creation/change workflow for the vendor or customer master data without involving
development transport in SAP.
5.2 Future State
Project originally approved March 2018, some development already done that will
need to be re-evaluated and tested.

4/13/20 update: For reduction in scope and cost the following assumptions are made.

• Central data will be governed by a separate prior process (Supplier Portal).

Self service workflow will center around site driven data (company code and
purchasing organization data)
• Multiple approver per site workflow step only sequential, use of substitution
and workflow admin tools to compensate for a missing agent due to out of office or
other reasons.
• Multiple sites contemporaneous site level changes must be handled on separate
CR’s. One for each site.
• Send to previous will not be permitted, only approve or send for revision
back to requestor.

There are 2 Parts in the way the future state will be delivered as shown below
Part 1: Self Service Levels
• Self Service Workflow: All sites (company code) will have the ability to set
up their approval process per site as per their Needs
• Self Service workflow will maintain Workflow approver levels for each site in
a custom table
• Self Service Workflow will have one step approval process from Requestor to
Site Controller
• Self Service Workflow will have Create and Change CR Types: ZS_CR, ZS_CH
• If CR is rejected by Data Steward or Site Controller then the CR is Final
Check Rejected for ZS_CR & ZS_CH

Part 2: Self Service Vendor

• Create Self Service Global Vendor and Change Self Service Global Vendor
Workflow will allow creation and change of vendor global data only. Company code
and Purchasing data will be hidden. Approval always sent to central body (CR types
ZS_SUP1, ZS_SUP2)

• Once BP and corresponding vendor is created using above process. Requestor

can extend Company Code and purchasing data using Parallel CR type Z_SITE
• In CR Type Z_SITE, only entities open for extension is Company code and
Purchasing Organisation.
• If only Purchase Organization is changed then the respective company code is
considered for the Workflow
• Only one site can be added / modified in the Z_SITE CR. Based on that it
will trigger the Self-service workflow for that site created in part 1.

6. Assumptions
Assumptions are things that are believed to be true but have not been confirmed.
Generally speaking, any assumptions that are not met become a risk. Enter N/A if
there are no assumptions.

- Question: In Create SS/Change SS there is only one approver Site controller,

same as FI. In this case, the question is if Tcode: ZMDGFI_SITE_CONT does not have
an entry for the site, what do we do?

Erwin Response: this would be rare in that the entire finance solution depends on
having controller assigned to the Site Controller groups at all times. I would not
want to use the FPA group default. I think for initial, this could be handled by
admin forward as not having a controller would be sending all the finance objects
to FPA as well, so it would be short lived. In this rare event , would SWU_OBUF
reinstate if one is assigned, or would SWIA be required?

- Question Same as above if for a site there is no entry in the level table
what to do? => BRD

Erwin Response: I don’t anticipate that this will not be the case, before a site
switches from current process to the new one, there will have to be a workflow at
least with the mandatory steps. On cutover we could simply set up all sites with
the minimum workflow to begin with, ie the stewards.

Handled in the cutover.

Note only level 1 has defaulted which is the data steward role. Role 2 to 9 is to
be set using a change request for each site. In this case, if I understand
correctly if level data (in rare cases) is empty. Then when data steward approves,
complete the workflow Response: yes.

7. Functional Requirements
Each requirement should be able to be traced to a test scenario.

Req. # Requirement Description (Input/Process/Output) Priority (H,M,L) In

Scope (Y/N) SSWF or CR?
1 Permitted actions:
Level 0 Requester Options:
• Reject => Withdraw the change request;
• Submit=> sends to next step (Re-Submit in case of a prior rejection).
Requestor can save a request, but not submit, in which case can return later to a
saved request, update it and submit. Once submitted and if there is a rejection,
the requester can edit data and resubmit.
Level 1 -8 Options:
• Reject=> sends to Requestor (Level 0);
• Approve=>sends to next step.

On reject options, notes of explanation are mandatory. In case of Approve notes are
optional

Level 9 Options:
• Reject=> sends to first step (Level 0);
• Approve=>Activation. This action is irrevocable, activation will initiate the
process to send the data to the targets, afterwhich the workflow ends and no
further processing can be done.
H Y CR
2
After workflow is completed send email to “governing body” client configurable
address list. Use DL to to be maintained in ZRange. That way the DL for “governing
body” can be maintained without having to re-configure anything this is on Create
and change scenarios.
H Y SSWF
3 Email notification by default should go out to requester after completion of
workflow, other approves do not need email.
H Y CR
4 Need a rule to allow only one selection per row for sequential
Assign multiple people to the same step with sequential selected. Result, multiple
people receive request, only one needs to approval.
1. Assign single person to the request marked sequential. Result, one person
approvals and moves to next step
H Y SSWF
5 Need a validation in place on user id to check if a person has a User ID in
MDP. If not, we need an error message that won’t allow the WF to move on but will
allow the requestor to save the request.
H Y SSWF
6 Active Directory sync with MDG would allow User ID and Title information to
be displayed on the MDG user interface. (Future enhancement) L Not in scope
SSWF
7 Default levels should be configurable via table based on the process
(Material, Vendor, Customer) Company code determines the workflow, Purchase org and
Plant are not relevant. Default level approver is based on Role, Role listed should
be the role ID not the role description.
Default levels cannot be deleted and must be defined.

For this Phase only Vendor levels will be configured. Future phases will include
customers and materials.

H Y SSWF
8 Make the 4th level mandatory not required Not in scope NA
9 SLA for create supplier and change supplier CR types 48 consecutive hours
(not business hours) to complete the whole CR. SLA for CR Type both create and
change also 48 hours to complete the whole CR. Once configured, Use existing
standard SLA report delivered by CR type.

H Y SSWF + CR
10 Send email notification after SLA breach to “governing body” client
configurable address list. Refer to 9 for breach definition

H Y CR + SSWF
11 Maximum levels: 9 levels H Y SSWF
12 Filter on Company code for the key fields when in the SSWF request process.
Purchase org and Plant fields are informational.
H Y SSWF
13 Workflow logic to run when CC is set and Plant is blank, Not applicable as
plant is informational H Not in scope CR
14 Validation: Users assigned at last level should be Approve ONLY! See 1 H
Y CR
15 Validation: User configured in level 9 should not be configured at any other
level.
H Y SSWF
16 Automation GRC creation when the user is not having access to SAP MDG .
(Future enhancement) L Not in scope SSWF
17 Notify Site Controllers for substituting users in self-service workflow when
they are terminated from Jabil . (Future enhancement) L Not in scope
SSWF
18 Create CR Type: Add step for a global approval process on create if no sites
are selected for an extension. Ie creating central data but not extending to any
company or purchasing org. Send to central body if there is no extensions.

In other words, in Create CR, only allow central data to be created and approval
will be sent to central body role.
H Y CR
19 Create CR Type: If more than 2 sites (use configurable threshold level) are
to be extended to use the same global approval step.
M Not in scope CR
19-a (Future enhancement). If more than one site is requested, the workflows will
default for now to those sites and CR will be locked until all approvals are
obtained. It is currently rare that over 2 sites are extended, Development needs to
be such that alternative routing is still possible for a future enhancement.
L Not in scope CR
20 Change CR Type: may need to call different workflow to accommodate this using
same table so will need to add indicator at each level showing that the level is
relevant for change only or Create only or both create and change relevant.
Level 1 which is mandatory by default would be relevant for both.
Last level which is mandatory by default would be relevant for both.
Inflight change requests (should a SSWF change be made) would continue to use the
configuration that was present when the CR was first submitted. Only new CR’s after
a change would be affected by the change.

Level 1 cannot be repeated: Display error message

H Y SSWF
21 Change CR type: “Global approval process” for changes to central data is
needed. To determine if central data is being changed, a compare the staging area
to active area of the central data (address, postal, tax,…) is taken for the CR
type. If any field in global area is changed from active area; This will determine
if FR22 or FR23.

Note the data elements that determined “central data” in staging area and active
data are should be defined in functional specification.

H Not in scope

Requirement changed, due to parallel CR. This point is not valid now CR
22 Change CR type: If it is determined that no central data is being changed
workflow can proceed as defined in the site SSWF set up and skipping the “Global
approval process”.

H Not in scope Requirement changed, due to parallel CR. This point is not
valid now CR
23 Change CR type: If it is determined that central data is being changed
workflow can will proceed to self-service workflow for the site only after “Global
approval process” See FR24

H Not in scope Requirement changed, due to parallel CR. This point is not
valid now CR
24 Change CR type: “Global approval process” will send a workflow step to the
Global Approval process agents. The Global approval process agents will be a group
of individuals defined thru role assignment or position that will follow a policy
to determine if they will reject (which returns the CR to the requestor) or approve
(which routes the CR to that site’s change workflow).

New role or position for the global approval process agents is needed to
accommodate FR 23

H Not in scope Requirement changed, due to parallel CR. This point is not
valid now CR
25 Change CR for central data. Only central data must be changed and must go to
central body for approval. Company and Purchasing Organization are read-only/hidden
H Y CR
26 Parallel CR type to be created for Site level workflow Process. Based on Site
or Purchasing Organization changed send to approvers as per self service table.

Allow only one site(company) or Purchasing Org to be added/modified per CR.

H Y CR
27 CR type is changed from Parallel to Single CR type for Site level workflow
Process. Based on Site or Purchasing Organization changed send to approvers as per
self service table.

Allow only one site(company) or Purchasing Org to be added/modified per CR.

 H Y CR
28 If CR is rejected by Data Steward or Site Controller then the CR is Final
Check Rejected for ZS_CR & ZS_CH
H Y ZS_CR, ZS_CH
29 Upon idoc replication of vendors with Medical company codes, the basic type
should be CREMAS05 and not CREMAS06 H Y ZS_SUP1
ZS_SUP2
Z_SITE

7.1 Validations and Derivations

Below is the list of Validations and Derivations that are to be implemented to
ensure that the data entered by the user is as desired.
Need a rule to allow only one selection per row for sequential vs parallel.
- Assign multiple people to the same step with sequential selected. Result,
multiple people receive request, only one needs to approval
- Assign single person to the request marked sequential. Result, one person
approvals and moves to next step

If multiple approvers at same level all must be marked as Sequential.

Display Error: Please check sequential for all level

SSWF FR4
Need a validation in place on user id to check if a person has a User ID in MDP.
If not, we need an error message that won’t allow the WF to move on but will allow
the requestor to save the request.

Logic:
Create Search help for Approver field on UI. Fill User id, First name, last name
and Title on UI

(USR02 table. Pass User ID in BNAME to USR21 table and you get PERSNUMBER. Pass
PERSNUMBER to ADRP table and you get First and Last Name and Title)

Display Error:” User XXXX does not exist”

SSWF FR5
Add validation to check All level approvers must have role ZD:MM_MDGS_APPROVER_GLBL
security role assigned to perform master data processing

Example “Role: ZD:MM_MDGS_APPROVER_GLBL not assigned to User XXXX”

SSWF FR5
Add validation Process and Company code mandatory.

Display Error “Please enter Process”

Display Error “Please enter Company code” SSWF FR5
Add Validation to make Level 9 mandatory
Display error “Please maintain Workflow Level 9”
Default levels should be configurable via table based on the process (Material,
Vendor, Customer) Company code determines the workflow, Purchase org and Plant are
not relevant. Default level approver is based on Role, Role listed should be the
role ID not the role description.
Default levels cannot be deleted and must be defined.

Logic:
ZMDG_SUS has the default levels

Key is Process. Read Process from ZMDG_SUS Table and fetch the data and fill on MDG
UI.
Populate Workflow level, User/Role ID, Seq from ZMDG_SUS to the MDG UI and make the
row non editable. In this phase it will be defaulted to Sequential in the ZMDG_SUS
table

SSWF FR5
SLA for create supplier and change supplier CR types 48 consecutive hours (not
business hours) to complete the whole CR. SLA for CR Type both create and change
also 48 hours to complete the whole CR. Once configured, Use existing standard SLA
report delivered by CR type.

Use Standard MDG Report: No development

SSWF + CR FR9
Set Priority for all 4 CRs Type as “DEFAULT”.
SSWF + CR FR9
Validation: User configured in level 9 should not be configured at any other level.

Display Error “User configured in level 9 should not be configured at any other
level” SSWF FR15
If there is only one approver at any level, it must be marked as Sequential.
Display Error:
“Please check sequential for all level” SSWF FR20
Validation to be added to allow only one site to created/changed in a Z_SITE CR
Type
Display Error if more than one is updated
CR New
additionally, we must see what the existing validation and derivations in Create
vendor global ZS4_1 and ZS4_2 CR Type and make sure they are implemented for above
2 new CR ZS_SUP1 and ZS_SUP2 types as well CR New
Level 1 cannot be repeated. Display error message SSWF New

For Z_SITE CR Type, add warning message at data steward step, which will be
displayed always
“Please change only one company code or purchase org”
Z_SITE CR Type New
In Z_SITE CR Type if user add/updates more than one Company code/Purchasing Org
then display error “Please reject the CR as more than one Company code or Purchase
Org is changed”

Z_SITE CR Type New

In Z_SITE CR Type in Steward step(20) if there are no changes done then display
error “Kindly do change in CR”

Z_SITE CR Type New

***Start of MDG CR Header Enhancement Requirements***
GBS Region: Add a new field with dropdown values AME, ASI, EUR which would be
single selection and editable until the final step of the CR activation. This would
be applicable for ZS_SUP1, ZS_SUP2 & Z_SITE CR types. This is a mandatory field. If
not filled a validation message appears “Please enter value for missing mandatory
fields”

Change Type: Add a new field with dropdown values: New, Change, Extended, Bank
Change, Mass Change, Rework & Payment Block as a dropdown field which would be
single selection and editable until the final step of the CR activation. This would
be applicable for ZS_SUP1, ZS_SUP2, Z_SITE. This is a mandatory field. If not
filled a validation message appears “Please enter value for missing mandatory
fields”

For ZS_SUP1 CR types – Change type field values are ‘New’, ‘Mass Change’ &
‘Rework’.

For ZS_SUP2, Z_SITE CR types – Change type field values are ‘Change’, ‘Bank
Change’, ‘Extend’, ‘Mass Change’ & ‘Rework’.

DUNS Number: It would be a text field with only Numerical Values of 9 characters
long, (no more & no less) OR the value ‘NODUNS’. This is a mandatory field. If not
filled a validation message appears “Please enter value for missing mandatory
fields”
It is added for ZS_SUP1, ZS_SUP2, Z_SITE

External Reference ID: It would be a text field with up to 20 chars applicable for
CR types ZS_SUP1, ZS_SUP2, Z_SITE

These values are saved against the CR number in a custom table ZMDG_CR_REQ_CC. This
table was used for saving the Requesting Company Code previously and this table
definition needs to be changed as below to accommodate the newly added field
values.

ZMDG_CR_REQ_CC
Field Names Length
Client 3
Change Request 12
Company Code 4
GBS Region 3
Change Type 15
Identification Number 60
External Reference ID 20

Code changes for saving the data from CR to table and reading it back when opening
a CR to be done

***End of MDG CR Header Enhancement Requirements*** Z_SITE, ZS_SUP1 & ZS_SUP2

New
Removal of Parallel CR Type to update the site data to BP as part of Portal
Requirement

Z_SITE CR type NEW

8. Non-Functional Requirements
The quality attributes, design and implementation constraints, and external
interfaces that the product must have. Non-functional Requirements are also known
as the following terms: Constraints, Quality Attributes, Quality Goals. Enter N/A
if there are no constraints.
Requirement 1

9. Impacts

10. User Interfaces / Selection Screen Layout (Mandatory for SAP Fiori and
Personas)
Provide an example and/or mock up of desired screen functionality. After each
mockup, please provide detailed information about the requirements. These
requirements should be cross referenced in the Systems Requirements section.

Site Approval Setup

• All sites will have the ability to set up their approval process per their
Needs
• Approval setup will have a workflow and approval process
• All maintenance will require Controller approval
• Custom data model and UI

Create Self Service UI:

List UIBB field details

Workflow Level: Drop Down: Level 1 to Level 9. Make it Mandatory Field

User: This will be a dropdown list that people can select from a populated backend
table. Search help. Make it Mandatory Field

Role: This will be populated from ZMDG_SUS table. Role ID of Default level.

Title, first name, Last name: These fields will be auto populated from the employee
and user tables. User ID will have a validation to stop the workflow if the person
selected does not have a user ID
This is a mandatory field

Sequential (Seq): Will dictate the flow of the workflow. This with the combination
of the steps will give us below potential options. This must be checked always
Options based on Sequential

1. Assign multiple people to the same step with sequential selected. Result,
multiple people receive request, only one needs to approval
2. Assign single person to the request marked sequential. Result, one person
approvals and moves to next step

Approvals:
The first step in the workflow will be static and cannot be changed by the users.
The step will be Data Steward.
Search Screen:

Edit Screen:

Search the required Site

Click on Site and then click on Edit

Self Service Vendor CR Types

1. For Z_SITE CR Type the attachment must be in scope. Requestor must click on
new button in attachment, add Valid From and Document Type and Description. Only
the requestor can Submit the CR

Note: CR Header will appear only after Requestor will click on New button in BP
Attachments

In case there is an error message that valid from and Document type already
existing. Please display error message to user asking the user to change the valid
from date.

11. Navigation

12. On-Screen Display

13. Outputs

13.1 To Screen
13.2 To Paper

14. Data Elements / Mapping

Provide data elements/mapping in the table below. Titles can be changed to meet
the needs of the application.

14.1 Data Model:

Data Model in MDG for Self Service:

14.2 Custom Tables:

1. Self Service Default Level Table

ZUSER not needed, it will always be a role.

2. Self Service Site Level table:

ZMDG_SELF_SERV_D: Only fields marked in yellow.
This table will get updated via RFC Replication after Self Service CR activation.

Note : We can keep the Parallel Checkbox, but it is not in scope for this phase.
15. Process Flow
15.1 User Flow

Where applicable, provide a flow chart depicting the process the user will follow.
15.1.1 Self Service Workflow
• This workflow will set up approval levels required for each site. This will
have CR type
- Create Self Service: ZS_CR
- Change Self Service: ZS_CH
• BRF Workflows to be implemented with one level approval.
• Requestor=> Site Controller=> Send Email to Governing body=> Workflow
completed.
a) Buttons for Requestor: Submit
b) Buttons for Site Controller: Approve, Reject
c) When Site controller Approves, it will send email to DL, and workflow is
completed with status Final check approved. Custom table will store the data for
the site after activation.
d) When CR is activated, data must be stored in custom table ZMDG_SELF_SERV_D.
This will store site and its corresponding workflow levels which will be utilized
in Create/Change Self-service vendor.
e) When Site controller Rejects, it will go back to Requestor
f) Buttons for Requestor: Resubmit, Withdraw
g) When Requestor resubmits, it will go to Site Controller. (Notes mandatory)
h) When Requestor withdraws, change request will complete with status Final
check Rejected
i) Make notes mandatory when Reject
j) When CR is activated, data must be stored in Custom table using RFC
Replication
Start of changes – PR42728:
k) Level 1 approver cannot be repeated in workflow
l) Search help is available for the field User with first name and last name

• Flowcharts

• Site Controller Approval Determination:

Once Requestor submits the CR, it will go to Site Controller for Approval.
Logic for Site Controller Determination to be used in Dynamic agent BADI in BRF
workflow:
Use the existing rule AC93500030 of PFAC to determine site controller approver for
the site in the Self-service workflow.
Call FM RH_RESOLVE_RESPONSIBILITIES to get Position for the site
Call FM SWI_GET_USERS_OF_ORG_UNIT to get users assigned to the position

Tcode: ZMDGFI_SITE_CONT
• Email Notification 1
Start of FR2:
After workflow is completed send email to “governing body” client configurable
address list. Use DL to be maintained in ZRange. That way the DL for “governing
body” can be maintained without having to re-configure anything this is on Create
and change scenarios.
End of FR2:

Receipent email: In ZRANGE Table , maintain below entry to store the DL to which
the email must go at end of workflow.
Application: MDG_SELFSERVICE
Program name: Workflow
Indentifier: MDG
Field name: DL
Number: 1
Sign: Include
Option: =
Low: xxxxxx@jabil.com

Below is the format of the email sent after workflow is completed. Send email in
all cases Final check approved, Final check rejected, Process error after
activation status.

Mail body details:

Dear Team,

Self Service Change Request <XXX> has status <Approved/Rejected/Process error after
activation>.
CR Description: <XXXX>
CR Notes: <XXXX>
Site: <XXX>
To access this change request, click below:
http://<XXXX>

Regards,
Master Data Governance

Reference existing code to send email: ZCL_MDG_ORG_CALL_SYS_METHOD

• Email Notification 2
FR10 => Send email notification after SLA breach to “governing body” client
configurable address list. Refer to 9 for breach definition

When SLA exceeds 48 hours send email to DL in ZRange Table

Receipent email: In ZRANGE Table , maintain below entry to store the DL to which
the email must go at end of workflow.
Application: MDG_SELFSERVICE
Program name: SLA
Indentifier: MDG
Field name: DL
Number: 1
Sign: Include
Option: =
Low: xxxxxx@jabil.com

Below is the format of the email sent when SLA exceeds 48 hours. After activation
write logic to check if Current time – CR Created time > 48 hours.

Subject Line: CR <XXX> SLA Violation

Dear Team,

Self Service Change Request <XXX> has status <Approved/Rejected/Process error after
activation> and SLA was exceeded.
CR Description: <XXXX>
CR Notes: <XXXX>
Site: <XXX>
To access this change request, click below:
http://<XXXX>

Regards,
Master Data Governance

15.1.2 Self Service Vendor Global Data Workflow

• This will have CR type

- Create Self Service Vendor Global: ZS_SUP1
- Change Self Service Vendor Global: ZS_SUP2
In above CR types will be like existing CR types ZS4_1 and ZS4_2. Only difference
is in this new CR types, only data that can be created/updated by data steward is
the Global data. Company code and Purchasing org UIBB are in display mode on MDG UI
for these CR types.
ZS_SUP1 and ZS_SUP2 workflow will be as below:
- Requestor will submit CR with only CR description=> CR will go to data
steward role give in ZMDG_SUS table who will enter global data and click on approve
=> CR will go to Central body for approval maintained in ZRANGE table
- Data Steward will be determined using ZMDG_SUS table for level1 and process
as VN

In ZRANGE Table , maintain below entry to store the Role for Central body.
Application: MDG_SELFSERVICE
Program name: Workflow
Indentifier: MDG
Field name: GLOBAL_PROCESS
Number: 1
Sign: Include
Option: =
Low: ZD:MM_MDGZS_CENTRAL_BODY (example)
15.1.3 Self Service Vendor Site Workflow
This will have CR Type : Z_SITE. The CR type will be marked as single parallel CR
type. This means it is possible to modify 2 or more sites of same BP in parallel
without locking the BP data. Each CR data will be activated in the backend after CR
activation.

In this CR type only entities that are editable is Company code(Site data) and
Purchasing data and BP Attachment. This is determined by the scope in the CR type.

The approval levels can be 1 to 9. Level 1 is fixed. Level 2 to 9 can have

approvers as per the self-service set for each site. Each level will have buttons
as per below table when approver receives the work item.

Permitted actions Withdraw Submit/ re-submit Reject (sends to requestor)

Approve Activate
Requestor (0) X X
First approver step Steward role (1) X X
Middle steps (2-8 for vendor) X X
Final step Approver X X

Process Flow:
Requestor=> Data Steward (Level1) => Site Approval Levels (Site data Changed Level
2 to 9) => Activate=>Workflow completed.

1. Requestor will create a Change Request and Submit. Requestor can only add
details in CR header section like CR description and attachments.
a. Remove Edit button for the rest of the entities
2. Once Requestor Submits, CR will go to level 1 which the data steward role
that is maintained in table ZMDG_SUS as per below role. Data Steward will add site
data and purchasing data and click on Approve.

3. After Data steward, workflow background step to check what data was changed.
Read change documents using class cl_usmd_adapter_provider. Method
>read_document_lines will give details of values changed in the CR by Data Steward
4. check if site data is changed(created/modified). Check number of sites that
are created/modified. Check entity BP_MLT_AS => BP_VENGEN=> BP_COMPNY and BP_PORG.
5. At Data Steward level Display warning message. “Only one Site/POrg can be
created or updated per CR”
6. If user changes more than one Company code or Purchase Org, display error
message “Please reject the CR as more than one Company code or Purchase Org was
changed”
7. Always display permanent information message: Please create/update only one
company code or Purchasing Org in the change request
8. User must click on attachment edit button to get the CR header. When user
enter a attachment if it says already locked based on date and document type.
Display error message to ask user to change the date.
9. If only one site is added / changed in a workflow, read the levels from
ZMDG_SELF_SERV_D.
10. At each level check Sequential WF checkbox checked.
If level is marked as Sequential and has multiple approvers, then all approvers
must get the same work item, and only one needs to approve. If reject send back to
requestor
If level is marked as Sequential and has single approver, then one approver must
approve to move to next step. If reject send back to requestor
11. At all levels except at data steward the company code and Purchase
Organization are read-only.
12. Once all levels in the CR are approved, activate the workflow and data is
stored in Backend.
13. Inflight change requests (should a SSWF change be made) would continue to use
the configuration that was present when the CR was first submitted. Only new CR’s
after a change would be affected by the change. Once CR is initiated store levels
for sites in the CR in a custom table
Custom table will have key as “Vendor” “Site” “Levels”. Once CR is completed clear
this temporary entry.

14. If only purchasing data is changed in a CR what is to be done? =>

Response: the Purchasing organization assignment table can be used to find the
relevant company code (Table T024E) and then determine the workflow for that
company code.

If V_T024E_ASSIGN has no company code for Purchase Org then use below logic
- For same PORG value find if there a company code in T001. If yes , send to
Company code Workflow
- If no same value in T001 . Then check in ZRange table as per below entry.
- No Zrange : workflow will break

Example: for 1813 Porg there is no Company code 1813 so we check in Zrange table
for its corresponding company code. Here we see it is assigned as 0155 and hence
0155 workflow steps will be used.

• Email Notification 1
FR3: Email notification by default should go out to requester after completion of
workflow, other approves do not need email. Add in all CR types ZS_SUP1, ZS_SUP2,
Z_SITE

Receipent email: Get Requestor of the workflow and find its email address
Below is the format of the email sent after workflow is completed. Send email in
all cases Final check approved, Final check rejected, Process error after
activation status.

Mail body details:

Dear Team,

Self Service Vendor Change Request <XXX> has status <Approved/Rejected/Process

error after activation>.
CR Type : <XXXX>
CR Type Description: <XXXX>
CR Description: <XXXX>
CR Notes: <XXXX>
BP Number: <XXX>
BP Name: <XXXX>

To access this change request, click below:

http://<XXXX>

Regards,
Master Data Governance
• Email Notification 2
FR10 => Send email notification after SLA breach to “governing body” client
configurable address list. Refer to 9 for breach definition

When SLA exceeds 48 hours send email to DL in Zrange Table

Receipent email: In ZRANGE Table , maintain below entry to store the DL to which
the email must go at end of workflow.
Application: MDG_SELFSERVICE
Program name: SLA
Indentifier: MDG
Field name: DL
Number: 2
Sign: Include
Option: =
Low: xxxxxx@jabil.com

Below is the format of the email sent when SLA exceeds 48 hours. After activation
write logic to check if Current time – CR Created time > 48 hours.

Subject Line: CR <XXX> SLA Violation

Dear Team,

Self Service Change Request <XXX> has status <Approved/Rejected/Process error after
activation> and SLA was exceeded.
CR Description: <XXXX>
CR Notes: <XXXX>
BP Number: <XXX>
BP Name: <XXXX>

To access this change request, click below:

http://<XXXX>

Regards,
Master Data Governance
Start of changes – PR42728 after Symphony changes
For all CR types ZS_SUP1, ZS_SUP2, ZSITE:
i) Remove any custom validations built on the fields under sections ‘Vendor:
Address’, ‘Email Address’, ‘Vendor: PO Box Address’. ‘Vendor: Communication’,
‘Vendor: Bank Accounts’
ii) Relationship entity is editable for ZS_SUP1, ZS_SUP2 & for ZSITE CR type as
Read Only
iii) ‘BP Type based on DUNS’, ‘Requesting Company Code’ & ‘Notes’ fields should be
visible for ZS_SUP1, ZS_SUP2, ZSITE CR types
iv) DUNS validation are as per the below attached Symphony FS
v) Add ZS_SUP1 & ZS_SUP2 in BRF rules wherever the old CR types are present
vi) Remove NEW button at vendor level

Symphony requirements for the reference:

**** MDG S/4 Integration Starts****
FR-58 Create new CR types similar to ZS4_1, ZS4_2, ZS4_004, ZS4_006 [Current CR
types] (Z_SUP1, Z_SUP2, Z_SUP_PF, ZSUPPFCH Old CR Types) without the custom data
entities under the supplier level which holds the general data, remove any custom
validations built on the fields under sections ‘Vendor: Address’, ‘Email Address’,
‘Vendor: PO Box Address’. ‘Vendor: Communication’, ‘Vendor: Bank Accounts’
ZS4_1, ZS4_2 (Current) [Z_SUP1, Z_SUP2 Old CR types] - Used for ZVEN process
ZS4_004, ZS4_006 (Current) [Z_SUP_PF, ZSUPPFCH Old CR types] - Used for Z004, Z006
partner function process
FR-59 a) On the new CR types created, retain D&B API calls and integration which
is currently built in on the business partner (BP).
b) Retain Company Profile section and the D&B integration to populate the custom
fields under it.

c) Retain Legal Name, Trade Name and Trade Style Name in the Partner Details
section and its validation functionality.

FR-60 Bank data would need to be migrated to MDG, we would need to enable bank
related fields under the ‘Bank Accounts’ section. ‘Bank partner type’ field under
the supplier master is mapped to the ‘Bank Details ID’ under the Business Partner
and the rest of the fields match with the supplier’s naming convention. This
requires training and change management sessions for the GBS teams.
a) Modify the inbound logic in MDG where the CREMAS_SUSMM IDOC received from
PRD/NSP would use the E1LFBKM segment to populate the data to LFBK table instead of
ZMDG_COUPA_CI
b) Modify the Coupa CREMAS Message type logic so that ZRTLFA1 segment reads the
bank data needed from standard LFBK table. Currently, ZMDG_COUPA_CI table is used
to read the bank data.
c) Make the Bank Details ID field as option for change Business partner cases
where the bank data is already present*

FR-61 Enable mapping logic (if already not under CVI) to map the Tax 1,2,3,4 fields
at the supplier level to the tax category at the business partner level. (This
would require user training). A detailed mapping doc of tax numbers mapping to tax
categories need to be prepared by country based on SAP’s recommendation.
FR-62 a) Retain the ‘Switch Change’ button on the Change requests and its
associated functionality where we can reject the ‘create vendor global’ CR and
auto-create a ‘change vendor global’ CR with the BP details.
b) Retain all the developments related to partner function CR types in
conjunction is third party supplier CR types
FR-63 Enable CVI mapping and replication, so that all the BP data entered on the
MDG frontend UI would flow down to MDG backend holding the BP information and to
the supplier master’s general data.
FR-64 New BP Creation Process:
Requester:
Requester would submit a change request using the “Create Vendor Global’ CR as it
is today. (No changes technically).
Add a new custom field under the Change request tile for “Requesting Company Code”
which would reference to the company code table T001 and would be a search drop
down to select.
Data Custodian (DC):
a) Under ‘My Change Request’ workflow inbox, the DC would access the CR, download
the documents from the attachments section to review. Upon review, the DC would
select the BP Grouping, enters mandatory information like Name1, Search term,
Street, Country, Postal code and Region, click on the check or hit enter would make
a call to D&B through the current API we have and would result with information for
the DC to choose from.
b) On the D&B result pop screen, click on ‘Choose Supplier’, ‘Ok’ would populate
the DUNS chosen and if clicked on ‘Cancel’ and ‘Ok’ would result in the NODUNS
case. This functionality already exists, and we would need to retain it for BP
groupings ZVEN, Z004, Z006.
c) Since the supplier custom fields would not be available, the data maintenance is
carried on the BP’s general data which would consist of Name 1,2,3,4, Street,
Street 4/5/2/3, House Number, Region, Postal Code, District, Country, Email, Phone
number+ Ext, Fax Number+ Ext, Tax categories, Bank Account Information.
d) Company code and purchase org data are extended at the supplier level. Upon
activation, IDOC with supplier data would replicate to the commercial target system
and IDOC would be generated to Healthcare target based on the company code and
purchase org entered.
In ECC: Once the vendor IDOC is sent from MDG to ECC, the BP in ECC is created
automatically based on the CVI configuration
FR-65 In FR 63, currently, the replication logic works based on Z-mapping table
which holds the company code and the target system associated with it. We would
need to use this for SOA mapping as well.
FR-66 New BP Change Process:
Requester: The requester would search for the existing business partner based on
the Name/search term or the Business Partner ID. We also currently have HANA based
search which the users can leverage. Once the Business partner is found, the user
would click on the ‘Description’ of the BP to raise a ‘change vendor global’ CR
with approval attachments.

Data Custodian (DC): The DC can access the ‘change vendor global’ CR to make
changes to general, company code, and purchase org data or add any new org level
data extensions. Upon activation of the change request, the IDOC will be activated
and send the data to pre S/4 Commercial target AND/OR to Healthcare target based on
the company code and purchasing org. extension using the Z table mapping which
currently exists in MDG.

In ECC: Once the vendor IDOC is sent from MDG to ECC, the BP in ECC is changed
automatically based on the CVI configuration
FR-67 BP Extension, Using Switch Change Functionality:
Requester: User raises a ‘create vendor global’ change request not realizing that
there already exists a business partner that they can leverage to extend.
Data Custodian (DC): Once realizing that a BP already exists in MDG, the DC would
use the current switch change functionality wherein they enter the BP number in the
notes section and click on ‘Switch Change’ option which would reject and close the
existing create CR and would auto-create a ‘change vendor global’ CR with the BP
that is required to process.
FR-68 Create Duplicate BP: We would leverage ‘Relationships’, to create duplicate
BPs when required, the BP screen under the Relationships tab would need to have all
the BP data fields, BP roles, D&B enhancements, supplier details same as Primary
BPs.
For ZVEN Grouping: Applicable BP roles would be FLVN00, FLVN01
For Z004 Grouping: FLVN00
For Z006 Grouping: FLVN01

Need to perform screen enhancement to the relationships BP tab to reflect the

screen options applicable to main BP.
FR-69 For all the above create and change scenarios, upon CR activation, the BP
general data on frontend would need to be mapped to be BP backend and as well as
supplier general data fields for all the account groups namely ZVEN, Z004, Z006 and
any account groups we may govern in future
FR-70

Data Conversion Activities:

a) All the ZDUP account group suppliers would be converted to ZVEN account group
suppliers as ZDUP BP grouping does not exist and we do not want to create as there
is no new business need and we would use Relationships with ZVEN BP grouping to
identify duplicates
b) Use standard CVI program to generate new BPs for all the duplicate suppliers
that currently exist in MDG.
c) Need to identify/ build a program to attach all the duplicate BPs as a
Relationship to a given Primary BP
d) Convert any orphan Z004 and Z006 suppliers to their respective BP.
e) Remove the ability to add any duplicate vendors on a BP
FR-71 Assess any impacts to Data Services (BODS, Information Steward).
FR-72 For Change Type CRs (ZVEN/Z004/Z006), the DUNS field would be open to Edit.
We need to add validation of the DUNS number either to be 9 digits numeric or
NODUNS. The DUNS on the BP and at the supplier level stored under credit info. The
number field should always match.
FR-73 Relationship category: This UIBB will be editable in both main and duplicate
BP. In Duplicate BP, the system will check if the Duplicate checkbox is ticked.
If yes, it should not allow deleting the existing ZCat relationship between Main
and Duplicate.
It should not allow adding another ZCat in the Relationship
In Main BP also, If the user enters new Zcat manually then check if the DUNS is a
match to the main if not show error message " For ZCat the DUNS must match the Main
BP"

FR-74 For the CR attachments download, modify the program to download the
attachments in a folder with naming convention to “CR Number_BP Number”
FR-75 Disable the old data model used in MDG and decommission the old CR types and
enhancements related to old model
FR-76 a)IBAN data on supplier bank data to be sent from MDG to Commercial/
Healthcare instances using the CREMAS_SUSMM message type and populate in target
systems

b)Enable BRF rules to make Language EN as default for all new CR types.

c)Create a custom filed on MDG frontend for the “Comments” field, it should read of
the data on the “Comments” which is on the BP backedn transaction which is
connected through CVI with vendor’s “Notes” field

End of changes – PR42728 after Symphony changes

15.1.4 Replication to Target systems

All CR types ZS_SUP1, ZS_SUP2, Z_SITE => Replication must be configured same as the
existing ZS4_1 and ZS4_2 (Z_SUP1, Z_SUP2 – Old CR types)
Existing Development must be checked to see if we need to incorporate above CR
types.
Changes in New CR Type:
1. Only general data: In ZS4_1 (old Z_SUP1), IDOC is sent to Commercial by
default. We ignore that logic for new CR type ZS_SUP1
2. New CR type ZS_SUP2 [like ZS4_2 (Old Z_SUP2)] and Z_SITE:
a. If no CC and no PORG, => No IDOC
b. If only company code, send as per Company code
c. If only PORG => Send to Commercial

15.2 System Flow

Where applicable, provide a flow chart depicting the process the system will
follow.

16. Technical Architecture / Design and Signoff (Optional, but recommended)

16.1 Technical Documents
FS Version Description Link (if necessary) Architect/Lead Signoff

16.2 Notes to Developer

16.3 ZRANGE Entries Applicable (Yes / No)

DL will be replaced as per business DL value.

17. Security Details (SAP T-code / Role Assignment)

17.1 Segregation of Duty Considerations
*****Start Version 1.0 *****
SD-1 New Security role to allow users to maintain the default levels table (see
FR-7)
SD-2 New Z-transaction that allows maintenance of the default levels tables (see
FR-7)
SD-3 New Security role for maintenance of MDG Self Service workflow objects
SD-4 ZS_CR , ZS_CH : Self Service CR Type Role
SD-5 ZS_SUP1 , ZS_SUP2, Z_SITE : Self Service Vendor CR types
SD-6 New role for central body approver
SD-7 New role for data stewardS

New Roles created

 ZS:MDG_MENU_SELF_SERV_GLBL : MDG Self Service Governance

(Security Form 8745,8920 for LPD_CUST)

 ZA:MDG_CENT_BODY_APPR_GLBL => Master Data Governance for Business Partner:

Central
(Security Form 8829)

 ZA:MDG_DATA_STEW_APPR_GLBL => Master Data Governance for Business

Partner:Data Steward
(Security Form 8867)

Existing Roles Updated:

To below roles: Type of Change Request: ZS_SUP1, ZS_SUP2, Z_SITE added (Security
Form 8868)

• ZS_GLOBAL_MDGBP_MENU_BP
• ZS_GLOBAL_MDGBP_MENU_BP_NEW

17.1.1 What standard transaction is this custom T-code similar to or “like”?

New Z transaction is similar to SM30
*****End Version 1.0 *****
*****Start Version 1.2 *****
17.1.2 What activity Group will be used to hold the T-code of this program?
Data steward/approver team at Jabil Sites
17.1.3 In case of a custom program, what security objects should be considered
for access control?
Custom authorization objects assigned to security role. Check for authorization of
user against the custom authorization object in the custom program for default
levels tables maintenance (SD-2) and maintenance of MDG Self Service workflow
objects (SD-3)
17.1.4 Has this T-code been reviewed by Corporate Finance?
17.1.5 Will this T-code be required to be entered in SAP Risk Analysis and
Remediation application (Compliance Calibrator)?
*****End Version 1.2 *****
17.2 Authorization Objects (Mandatory for SAP Fiori)

17.3 Web Application (Yes / No)

17.3.1 If Yes, then need to submit for IT Security testing.

18. Testing Scope and Requirements (Mandatory)

18.1 Scenario descriptions and expected results
18.2 Scope of Tests (List all aspects as to what the test scripts should contain)
<To be added>
18.3 Assumptions
18.4 Prerequisites (List all master data elements that are to be used/created, and
organizational objects that need to be considered)

19. Approvals (Mandatory)

19.1 Requestor Approval (Screenshot Required):

--End of document--