1

MAHLE Business Owner Jan Ziekursch

MAHLE IT Owner
EY Solution Owner Karsten Scheibe
Reviewers Sven Bresser
Business Approvers
Status
Repository
Document ID MORE-297 Approval Workflow

Change History:

Version Description of changes Date Author Approver Approver’s Approval

position date
0.1 First draft 14.11.20 Karsten
18 Scheibe
0.2 Added details on PO 16.11.20 Karsten
workflow 18 Scheibe
0.3 Extension of chapters 3 30.11.20 Karsten
and 4 18 Scheibe
1.0 Version for review 14.12.20 Karsten
18 Scheibe
2.0 Smaller wording 09.01.20 Karsten
corrections 19 Scheibe
Added ASG reference
(3.2.1)
Added usage of BRFplus ()
3.0 Changes after review on 18.01.20 Karsten
16.01.2019 19 Scheibe
4.0 Removal of Enhancements 31.01.20 Karsten
after Governance Board 19 Scheibe
decision
5.0 Added implementation 15.03.20 Karsten
details 19 Scheibe
Adjustments to concept
after first test runs
6.0 Added implementation 19.03.20 Karsten
details 19 Scheibe
Added details on item /
account selection
7.0 Finalized version for 23.04.20 Karsten
release 1 19 Scheibe
8.0 Including buyer in workflow 09.05.20 Karsten
19 Scheibe
9.0 Change to determination of 11.06.20 Karsten
cost center responsible 19 Scheibe
10.0 Added details about 09.08.20 Sven Bresser
approval information & 19
error handling
11.0 Adapted PR / PO Workflow 29.08.20 Sven Bresser
logic 19
(Chapter 3.2)

MAHLE International GmbH,

Stuttgart
Project MORE
 2

Contents
1 General information.................................................................5
1.1 Authors of the Concept and Solutions resolution document..................5
1.2 Review list............................................................................................. 5
1.3 Approval/Sign-off list.............................................................................. 5
2 Introduction.............................................................................6
3 Context....................................................................................7
3.1 Process Overview.................................................................................. 7
3.2 Approval Steps...................................................................................... 10
3.2.1 Approver Determination Rules at MAHLE..........................................10
3.2.2 Purchase Requisition Approval..........................................................14
3.2.3 Purchase Order Approval...................................................................15
3.3 Process Descriptions.............................................................................. 17
3.3.1 Create Purchase Requisition – Procurement Hub...............................17
3.3.2 Create Purchase Requisition – Guided Buying...................................21
3.3.3 Approve Purchase Requisition...........................................................25
3.3.4 Conversion to Purchase Order...........................................................29
3.3.5 Transfer Purchase Order to Hub........................................................29
3.3.6 Approve Purchase Order....................................................................30
3.3.7 Cancel / Recall / Restart Workflow.....................................................31
3.4 Additional Requirements.......................................................................32
3.4.1 Handling of Approval Notes...............................................................32
3.4.2 Four-Eyes Principle (Approver = Requester)......................................32
3.4.3 Mail Notifications............................................................................... 32
3.4.4 Reminder / Escalation Process...........................................................32
3.4.5 Error Handling / Workflow Administration..........................................33
3.4.6 Approval Preview...............................................................................34
3.4.7 Substitution Rules..............................................................................34
3.4.8 Approval workflow history.................................................................35
3.5 Out of Scope.......................................................................................... 35
4 Solution Design........................................................................36
4.1 System Landscape / Architecture..........................................................36

MAHLE International GmbH,

Stuttgart
Project MORE
 3

4.2 Workflow Framework.............................................................................37

4.3 Customizing........................................................................................... 38
4.3.1 Activation of Workflow Framework....................................................38
4.3.2 Activation of Workflow Scenario........................................................39
4.3.3 Definition of Approval Steps..............................................................40
4.3.4 Maintenance of Approver Determination Rules.................................43
4.3.5 Automatic Creation of Purchase Orders for Requisitions from Hub
(Backend).......................................................................................... 44
4.3.6 Activation of Central Purchase Order Workflow (Backend)................45
4.3.7 Dummy Release Strategy (Backend).................................................46
4.3.8 Maintenance of Mail Templates.........................................................48
4.4 Custom Developments..........................................................................49
4.4.1 Creation of Custom Workflow Scenarios............................................49
4.4.2 Adjustments to Standard UIs.............................................................63
4.4.3 Change fields in Workflow / Workflow Restart...................................63
4.4.4 Attachment Display in “My Inbox” for PRs.........................................64
4.4.5 Reminder / Escalation Process...........................................................65
4.4.6 Workflow Notifications.......................................................................65
4.4.7 Info Message on Workflow Restart.....................................................66
4.4.8 Filter PR Items in “My Inbox”.............................................................67
4.5 Outlook on Takeover into the S4 Template System...............................68
5 Outlook on Next Releases.........................................................69
6 Impact Estimation....................................................................70
6.1 Global Template.................................................................................... 70
6.2 Business Processes................................................................................ 70
6.3 Testing................................................................................................... 70
7 Implementation Details.............................................................71
7.1 Customizing........................................................................................... 71
7.1.1 Basic Workflow Setup........................................................................71
7.1.2 Activation of Workflow Framework....................................................71
7.1.3 Activation of Workflow Scenario........................................................71
7.1.4 Activation of Apps for Workflow Management...................................72
7.1.5 Settings for App “My Inbox”..............................................................73
7.1.6 Approver Determination Rules...........................................................74

MAHLE International GmbH,

Stuttgart
Project MORE
 4

7.1.7 Configuration of Workflow Mail Notifications / Reminders.................76

7.2 Development......................................................................................... 78
7.2.1 Class Overview.................................................................................. 78
7.2.2 Workflow Scenarios........................................................................... 81
7.2.3 Business Rules................................................................................... 86
7.2.4 Processing of Workitems...................................................................86
7.2.5 Tool Classes....................................................................................... 87
7.3 Miscellaneous........................................................................................ 88
7.3.1 BRFplus Trace.................................................................................... 88
8 Related Documents..................................................................90

MAHLE International GmbH,

Stuttgart
Project MORE
 5

1 General information
1.1 Authors of the Concept and Solutions resolution document

This document was written by the following individuals:

Name Role
Karsten Scheibe Functional / Technical Consultant

1.2 Review list

Prior to the approval of the design, the following individuals have reviewed this
document:
Name Role
Sven Bresser Functional Consultant

1.3 Approval/Sign-off list

Name Role
Herr Ehrhardt Controlling & Systems Global Purchasing Non Production Material
(TXC)

MAHLE International GmbH,

Stuttgart
Project MORE
 6

2 Introduction
The purpose of this document is to describe the concept and solution for the MORE
template for the respective user story in terms of system functionality (customizing
rationale and enhancements).

MAHLE International GmbH,

Stuttgart
Project MORE
 7

3 Context
In this chapter, the proposed solution is described from a functional perspective.

3.1 Process Overview

The procurement approval process at MAHLE consists of two main parts:

- Purchase requisition approval and

- Purchase order approval

The following overview shows the integration of the approval processes into the
high-level end-to-end procurement process.

Figure 1 - Workflow within E2E procurement process

Purchase requisitions will be created by employees either directly in the central

procurement hub using Fiori apps or by using the Ariba Guided Buying integration.
An upload of requisitions from connected ERP or S/4HANA backend systems is also
possible but currently not in scope.
Approved purchase requisitions can be bundled and converted into purchase orders.
This can happen either manually or automatically.
The created purchase orders will be subject to a second approval workflow. Once
finished, the finalized document will be sent to the supplier.
This document will focus on the highlighted approval steps within the process but will
also include references to other parts, where necessary.

MAHLE International GmbH,

Stuttgart
Project MORE
 8

The rough process flow of the purchase requisition approval is as follows:

MAHLE International GmbH,

Stuttgart
Project MORE
 9

Figure 2 - Process Flow Purchase Requisition

MAHLE International GmbH,

Stuttgart
Project MORE
 10

Due to the involvement of the purchasing department in the purchase requisition

approval process, the conversion of the finalized requirement to a purchase order
can be done automatically in most cases.
When the order was created from a pre-approved and –checked requisition, the
approval process for the purchase order can also be shortened. The following chart
gives an overview on the purchase order approval process:

MAHLE International GmbH,

Stuttgart
Project MORE
 11

MAHLE International GmbH,

Stuttgart
Project MORE
 12

Figure 3 - Process Flow Central Purchase Order

3.2 Approval Steps

The following tables provide an overview and description of the different approval
steps (internal, external and optional approvals) including the following information:

MAHLE International GmbH,

Stuttgart
Project MORE
 13

- In which cases is the approval required? (“start criteria”)

- Who needs to approve? (“approver determination”)
- Is the decision executed on header or item level? Is the assignment of multiple
approvers possible?
- Which fields may be changed by the approver?

3.2.1 Approver Determination Rules at MAHLE

The determination of responsible approvers at MAHLE is based on the “Approval and

Signature Guidelines” (ASG) that are currently maintained in a Lotus Notes database.
Various criteria are checked to find the right approvers, which are HR (like
organizational assignment, functional group) as well as business document related
(like material group and total order value).
Some parts of the needed information can already be delivered by the existing MIAM
interface (MAHLE user ID, job description, region, company, plant), others are
planned to be added to MIAM / HR (business role). Only purely procurement related
rules would be maintained in the procurement hub (e.g. material group based
exceptions).
For implementing release 1, the approvers will be maintained locally in the
Procurement Hub, as the MIAM interface is not yet ready. Once available, it will be
connected to the Hub and the local approver determination will be switched off.
The approver determination will be done according to the following high-level flow:

- The purchase requisition / purchase order data will be evaluated in the Hub
according to the ASG and the roles responsible for approval will be determined
(e.g. line manager, plant manager or regional manager)
- As there are different rules for different ASG roles to identify the correct
person, a table will be created to define which rule is the correct one to
identify the correct person.

Example for table:

ASG role Description Rule Rule explanation
number
100 Responsible R01 Cost centre owner (or Boss in line
department organisation)
…
110 Purchasing R02 Buyer code (e.g. W01, W02, …)
employee
…
935 Resp. purchasign R03 Lock up person in table accordin to
NPM world ASG role

MAHLE International GmbH,

Stuttgart
Project MORE
 14

(“assignment of approver to
codes”)

If there is no rule number assigned in the table than the fall back rule is the R01 rule
(= cost center owner + boss in line organisation)

MAHLE International GmbH,

Stuttgart
Project MORE
 15

As of today, the following rules are needed.

rule number rule name description

R01 cost center look up cost center owner based on cost center in
PR + Boss ID-Logic (If the user is not found or the
role code of the user is < the required code, the
BOSS ID of the user will be determined and the
same things are checked again. This will continue
until we either find an appropriate approver or the
end of the approval hierarchy is reached
R02 buyer code identify person based on buyer code (PGrp) in PR
R03 ASG_approver identify person in table “ASG_approver”
R04 PR creator person who created the PR (automatical approval)
R05 Staff external person who created the PR (automatical approval)
 PO without PR: cost center owner (R01)
Rxx… tbd not needed at the moment (possible to define
further roles in future)

This table with the rules should be editable so that further rules can be added in the
future.
Related to Rule 03, there should be exactly one person determined. Therefore, the
following information and parameters needs be added to the existing “ASG
approver” list:
Existing parameters:

- MAHLE User ID
- ASG Role number

Additional parameters:

- Region
- Country
- Material group code range
- SAP plant code
- Log System

The additional parameters are needed twice, on the one hand for internal ASG role
and on the other hand for external ASG role (e.g. it is possible that one person has
internal an ASG role just for DE but an external ASG role with responsibility for EU in
total).

MAHLE International GmbH,

Stuttgart
Project MORE
 16

Due to this, a table will be implemented to define the region and country by SAP
plant code which enable MAHLE to maintain in “ASG approver” table just the region
or country instead of naming all plant codes.

Example for table:

log system plant code SAP country region

SAP_P50 1001 DE EU
SAP_P50 1080 PL EU
… … … …
SAP_PRD 1010 US NA

- The determined role and specific document data (accounting responsible, total
value, account assignment) will be passed to the local approver table / MIAM
interface, which returns the responsible user(s)

- In some exceptions, MAHLE needs the possibility to overwrite the approver

returned from MIAM / local table. Therefore, a table will be implemented to
allow the maintenance of these exceptions rules. These rules will be always
evaluated. If a matching exception rule is found, the approver delivered by
MIAM / local table will be overwritten.

- MAHLE wants also the possibility to activate some additional steps. Therefore,
two optional workflow steps will be implemented within the PR and one will be
implemented within the CPO workflow for special cases. These steps can be
maintained within a table, the user IDs are assigned directly (not via business
role codes).

For release 1, a local version of the ASG containing all relevant entries for the pilot
will be maintained in the Hub (as a BRFplus decision table). In the next step, a global
solution will be developed by the Architecture stream.

MAHLE International GmbH,

Stuttgart
Project MORE
 17

3.2.2 Purchase Requisition Approval

Approval Start Criteria Level Approver Changeability Comments

Step Determination

ASG Internal Maintained in Head Business role according to Add notes /

1 BRFplus er ASG attachments to
User for role via MIAM workitem
interface

Optional 1 Maintained in Head Approver user maintained Add notes /

BRFplus er in BRFplus (only relevant attachments to
for exceptional cases) workitem

ASG External Maintained in Head Business role according to Add notes /

1Buyer BRFplus er ASG attachments to
User for role via MIAM workitem
interfaceAs defined in the
Hub’s purchasing group
customizing (temporary
solution for release 1)

Optional 2 Maintained in Head Approver user maintained Add notes /

BRFplus er in BRFplus (only relevant attachments to
for exceptional cases) workitem

ASG Internal Maintained in Head Business role according to Add notes /

2 BRFplus er ASG attachments to
User for role via MIAM workitem
interface

The following document data will be evaluated for approver determination:

- Total value of requisition

- Catalog indicator of all items
- Company code, plant and material group from the item with the highest value

Although item-based approval is possible for purchase requisitions, it comes with

severe drawbacks in terms of usability. A distinct workitem is generated for each
item of the requisition that also needs to be processed separately. This means, there
is no single entry point, where the approver gets an overview of all items he has to
approve.
Example – Requisition with two items:

Two work items are generated which need to be processed independently:

MAHLE International GmbH,

Stuttgart
Project MORE
 18

Due to this restriction, header-based approval will be used. With this approach, it
is still possible to assign multiple approvers to the same approval step (e.g. based on
material groups or account assignments). All users receive a workitem in parallel and
have to processes it before the next approval step is started. The main difference to
the item-based approval is that each approver has to decide on the whole document
and not just a specific set of items.
If needed, it would be possible to extend the UIs, so that the approver only sees the
items relevant for him. A solution proposal and effort estimation is provided in
chapter 4.4.8.
The possibility to change document data within the “My Inbox” app is not
supported in the standard delivery. In the current release 1809, only the requester is
able to change his requisition using the App “My Purchase Requisitions”. Other
parties (approvers, purchasing department) can only change the follow-on document
in the backend system after the approval is finished or ask the requester to do a
change.
Links to the detail apps are provided within the displayed overview information or in
the tab “Related Objects” (display only):

MAHLE International GmbH,

Stuttgart
Project MORE
 19

The toolbar button “Open Task” is not available for requisition related approval steps
(due to a new technical foundation).

3.2.3 Purchase Order Approval

Approval Start Leve Approver Changeability Comments

Step Criteria l Determination

ASG External Active, if not Head Business role according to Complete Changes may trigger
1 executed on er ASG document (in workflow restart
PR levelif the User for role via MIAM backend
responsible interface transaction)
user is not
equal to the
buyer who
approved
the PR

Optional Maintained Head Approver user maintained Add notes /

in BRFplus er in BRFplus (only relevant attachments to
for exceptional cases) workitem

ASG External Maintained Head Business role according to Complete Changes may trigger
2 in BRFplus er ASG document (in workflow restart
User for role via MIAM backend
interface transaction)

The following document data will be evaluated for approver determination:

- Total value of the order

- Catalog indicator of all items
- Company code and plant from the PO header
- Material group from the item with the highest value

For purchase order approval, no item-based workflow template is available in the

system. Therefore, the same header-based approach as described for purchase
requisitions above will be used.
MAHLE International GmbH,
Stuttgart
Project MORE
 20

The details of the purchase order can be opened using the link “Open Task” in the
bottom toolbar:

For changing document data, it is necessary to open the transaction “Change

Purchase Order” in the corresponding backend system, as changes within in
Procurement Hub are not supported. For doing so, the link “Open Document” is
provided which directly navigates to the corresponding backend system.

After a change has been done, the updated order will be uploaded to the hub again
and the workflow will be restarted if relevant changes were made.

3.3 Process Descriptions

The following chapters are a walkthrough though the different apps and transactions
involved in the process from requisition creation to the finalized and approved order.
This includes the approval processing for both requisitions and orders.

MAHLE International GmbH,

Stuttgart
Project MORE
 21

3.3.1 Create Purchase Requisition – Procurement Hub

App / Role Additional Info

Transaction

Create Purchase Employ https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/#/

Requisition (Self- ee detail/Apps('F1643')/S12OP
Service)

Manage Purchase Purchas https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/#/

Requisition er detail/Apps('F2229')/S12OP
Professional

Create Purchase Purchas https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/#/

Requisition er detail/Apps('ME51N')/S12OP
Advanced
(ME51N)

Several apps are available for the creation of purchase requisitions: The employee
may use either the self-service (SSP) app or Ariba Guided Buying integration (see
chapter 3.3.2). The purchaser additionally has access to a professional requisition
management app as well as the classical SAPGUI transaction ME51N (delivered as a
webpage).
The following screenshots show the requisition creation process using the SSP app.
After logging on, the user starts the “Create Purchase Requisition” app:

The user will receive a notification on the company code and plant he is currently
assigned to and is able to add items to his cart:

MAHLE International GmbH,

Stuttgart
Project MORE
 22

In the next screen, the basic data of the item can be entered:

It is also possible to assign a fixed / preferred supplier and to add attachments and
notes:

MAHLE International GmbH,

Stuttgart
Project MORE
 23

After pressing “Add to Cart”, the overview in the upper right corner will be updated:

Back in the main screen, a summary of the cart is shown and the user can navigate
to the item again in order to change further details like organizational and account
assignment:

MAHLE International GmbH,

Stuttgart
Project MORE
 24

Finally, the cart can be ordered. If no error occurs, a purchase requisition will be
created in the hub:

MAHLE International GmbH,

Stuttgart
Project MORE
 25

If a workflow is configured in the system, the requisition will be sent into approval:

3.3.2 Create Purchase Requisition – Guided Buying

As already mentioned in the last chapter, several apps are available for the creation
of purchase requisitions: The employee may use either the self-service (SSP) app or
Ariba Guided Buying integration.
The following screenshots show the requisition creation process using the eBuy
(Ariba Guided Buying integration).
After logging into the S/4HANA Procurement HUB Fiori Launchpad, the user starts the
“eBuy” app:

MAHLE International GmbH,

Stuttgart
Project MORE
 26

The user will routed to the MAHLE Ariba GB Landing page.

Here the user has different options to create a PR (e.g. use catalog search or ad hoc
items).
After the user found the article he can add the item to the Shopping Cart.

After pressing “Add to Cart”, the overview in the upper right corner will be updated:

MAHLE International GmbH,

Stuttgart
Project MORE
 27

In the next step the user have to “check out” the shopping cart by clicking on “check
out”.
Here, a summary of the cart is shown and the user can navigate to the item again in
order to change further details like account assignment:

MAHLE International GmbH,

Stuttgart
Project MORE
 28

Here it is also possible to leave the supplier field empty for ad hoc items.

MAHLE International GmbH,

Stuttgart
Project MORE
 29

The possibility to transfer text ids & attachments from Ariba GB into the
Procurement HUB is not supported in the current release 1809 (should be available
with Release 1909). This means that the requester have to add notes, comments &
attachments while the PR approval workflow directly in procurement Hub in the
application “My Purchase Requistions” after the Ariba GB PR creation.
Finally, the Request can be created by clicking on “Send Request”. If no error occurs,
a purchase requisition will be created in the Ariba GB & Procurement Hub:

MAHLE International GmbH,

Stuttgart
Project MORE
 30

If a workflow is configured in the system, the requisition will be sent into approval
(HUB).
The status is in Ariba GB under “Your Requests” & in Procurement HUB under My
Purchase Requisitions visible.
Ariba GB:

Procurement HUB:

MAHLE International GmbH,

Stuttgart
Project MORE
 31

3.3.3 Approve Purchase Requisition

App / Role Additional Info

Transaction

My Inbox Approve https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/#/

r detail/Apps('F0862')/S12OP

Approval of the requisition is done in the app “My Inbox” which displays all
workitems existing in the system. The specialized app “My Inbox – Approve Purchase
Requisitions” with a predefined filter on procurement workitems will not be used.
The app “My Inbox” can be opened using the corresponding tile. It also displays the
amount of open workitems the user is responsible for:

MAHLE International GmbH,

Stuttgart
Project MORE
 32

On the left side of the app, a list of all workitems will be shown, which can be sorted,
filtered and grouped, for example by task type:

On the right side, details on the currently selected workitem and the associated
business document will be displayed. In the bottom toolbar, the user can directly
approve or reject the workitem:

MAHLE International GmbH,

Stuttgart
Project MORE
 33

MAHLE International GmbH,

Stuttgart
Project MORE
 34

In the second tab, the user can add comments that are visible to all participants of
the workflow:

Attachments can be added on the third tab:

MAHLE International GmbH,

Stuttgart
Project MORE
 35

MAHLE International GmbH,

Stuttgart
Project MORE
 36

There are two types of attachments:

1) Attachments, which have been added within the workflow (can also be
deleted). These are only visible within the inbox.
2) Documents attached to the business object (for example by the requester).
These can be displayed here, but not changed.

The button “Show Log” can be used to display a log of past workflow activities:

MAHLE International GmbH,

Stuttgart
Project MORE
 37

If the user wants to display all details of the document or make changes, it can be
opened using the object link:

3.3.4 Conversion to Purchase Order

After the purchase requisition is approved, it will be transferred to the selected

backend system. The conversion to a purchase order can happen either
automatically or manually within the backend.
In order to execute an automatic conversion, the option “Automatic PO creation” has
to be activated in the vendor master and the customizing has to be set as described
in chapter 4.3.5. A manual conversion is possible with classical transactions like
ME21N and ME59N.

3.3.5 Transfer Purchase Order to Hub

App / Role Additional Info

Transaction

Schedule Import of Admin https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/

Purchasing #/detail/Apps('F3268')/S12OP
Documents

The upload of purchasing documents (purchase orders in this case) to the hub
system is usually scheduled as a periodic job by a system administrator. The
following app is provided for the necessary setup:

MAHLE International GmbH,

Stuttgart
Project MORE
 38

Details on the available options can be found in the app documentation.

3.3.6 Approve Purchase Order

App / Role Additional Info

Transaction

My Inbox Approve https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/#/

r detail/Apps('F0862')/S12OP

Purchase order approval is done within the central “My Inbox” app that collects all
open workitems of the user. For central purchase orders, no details are displayed in
the inbox at the moment. In order to check the document, the “Open Task” button is
provided (see chapter 3.2.3 for details).
MAHLE International GmbH,
Stuttgart
Project MORE
 39

All other available functions are working in the same way as for purchase
requisitions.

3.3.7 Cancel / Recall / Restart Workflow

There is no special action for the requester to cancel or recall a running workflow.

The user is able to delete his requisition or change it, which could trigger a workflow
restart according to the following restart criteria:

- For purchase requisitions: The fields described in note

https://launchpad.support.sap.com/#/notes/0002665086 will trigger a
workflow restart
- For purchase orders: Per default, all changes transmitted from the backend
will trigger a workflow restart.

For release 1, the restart logic of SAP as described above will be used for both
purchase requisitions and purchase orders. An additional warning message on
possible workflow restarts is also not in scope for the first release.
During the pilot phase, the necessity of these extensions will be evaluated again.

MAHLE International GmbH,

Stuttgart
Project MORE
 40

3.4 Additional Requirements

In the following chapters, functional requirements will be described, which are

relevant for the whole workflow or multiple approval steps.

3.4.1 Handling of Approval Notes

When accepting or rejecting a workitem, a dialog will be shown to the approver

where he can enter a reason for this decision.

This note should be optional in case of approval and mandatory in case of rejection.

For release 1: Rejection notes are not visible for the requester in release 1809. This
functionality will be part of the Release 1909.

3.4.2 Four-Eyes Principle (Approver = Requester)

The four-eyes principle will already be ensured by the approver determination rules
(based on the MAHLE signature guidelines). There is no need for the implementation
of special logic within the workflow to handle this case.
If the requester is determined as one of the responsible approvers of his own
document, the approval step will be skipped.

3.4.3 Mail Notifications

S/4HANA supports the generation of mail notifications when a workitem is assigned

or forwarded to a new approver. The corresponding mail looks as follows:

Although it is possible to adjust the mail text, no additional information from the
business document can be added at the moment (like price, item list). Therefore, a
custom mail will be implemented (see chapter 4.4.6 for details).

MAHLE International GmbH,

Stuttgart
Project MORE
 41

3.4.4 Reminder / Escalation Process

In order to speed up workflow processes and to avoid approvals being stuck, a

reminder and escalation process will be established.
Once a day, a job will check all open workitems and send a reminder mail to the
responsible approver when a specified time limit has been exceeded (notification
process). After a second time limit, the approver’s manager (identified via MIAM’s
BOSSID) will receive the notification in copy in order to take care for example in case
of absence (escalation process). A separate mail will be sent for each workitem
containing a direct link to open it in the inbox.
A customizing table should be available to set up the notification deadline and
intervals.
Example:
Task Notificatio After x Send Send Send to Mail
n Level Workdays each x to Approve Template
Workday Approv r’s
s er Manager

Approve 1 3 3 X ZREM_PR_1
PR

Approve 2 15 3 X X ZREM_PR_2
PR

Approve 1 3 3 X ZREM_PO_1
PO

Approve 2 15 3 X X ZREM_PO_2
PO

The feature “Deadline Monitoring” of SAP Business Workflow is not yet available for
the flexible workflow and does not provide the necessary flexibility (e.g. multiple
escalation levels and recipients).

3.4.5 Error Handling / Workflow Administration

In case of any errors (for example no approver was found in the determination), the
approval process will be stopped and log entries will be created (SWO1).
System administrator are able to use already known tools like transactions SWIA
and SWI2_DIAG to find and process erroneous workitems.
Furthermore, the workitem will be be forwarded to an admin which needs to be
maintained in a custom table. In addition to that, a mail will be send out to this
admin.
This mail should include the reason why the approver determination failed. It will
most likely because of one of the following reasons:

MAHLE International GmbH,

Stuttgart
Project MORE
 42

 Material group is not maintained in the ASG  PR will be approved

automatically
 Cost center responsible is not correctly determined  This can fail when there
is a technical issue (RFC connections not working) or if the fields in the
backends are empty
 Cost center responsible is not maintained in the ASG  It will go up in the
hierarchy and if the follow on user are also not there, no user will be
determined and workflow is stuck
 The determined user is not available as a SU01 user  the workflow will stop
 MIAM data are not available for the user  The Boss ID could not be
determined

3.4.6 Approval Preview

Once a purchase requisition is ordered, an approval overview is displayed:

In release 1809, no approval preview is available for purchase requisitions in draft

status and central purchase orders.

3.4.7 Substitution Rules

The SAP workflow system provides a standard mechanism to implement active

(vacation) and passive (sick leave) workflow substitutions. These are stored in the
tables HRUS_D2 and TWFS.

According to the current information, these rules will be maintained centrally using a
Fiori app and will be pushed to the Hub system. No additional actions need to be
taken for the Hub workflow.

The locally defined substitutes can be checked (and changed if the decision is to not
maintain them centrally) in the user menu while the “My Inbox” App is open:

MAHLE International GmbH,

Stuttgart
Project MORE
 43

3.4.8 Approval workflow history

The class CL_MMPUR_APPROVAL and method GET_SCN_WFL_INFO provide us all the

necessary details of the workflow history.

There the ET_WORKLIST parameter can be checked. Within this MAHLE can look at
entries with WI_TYPE as ‘W’ (dialog workitems where someone has to approve).
These entries have all the required details e.g. approver, when the work item got
created, status & when it was approved.

3.5 Out of Scope

Several points that were originally part of the concept’s first draft will be evaluated
again for the next releases. Please have a look at the outlook in chapter for details.

MAHLE International GmbH,

Stuttgart
Project MORE
 44

MAHLE International GmbH,

Stuttgart
Project MORE
 45

4 Solution Design
In the following chapters, you will find information on how the solution will be
implemented within the S4 procurement hub. This also includes information on the
required custom developments.

4.1 System Landscape / Architecture

The following systems are involved in the processing of purchase requisitions:

Figure 4 - System Architecture

New requisitions will be created in the S4 Procurement Hub (release 1809 on

premise) either directly or using the integration of Ariba Guided Buying. The hub is
also the central place where the approval workflow will be executed.

MAHLE International GmbH,

Stuttgart
Project MORE
 46

The Procurement Hub will also be used as the frontend server for all Fiori apps
(embedded gateway deployment) mentioned in this concept. This excludes the
app “My Inbox” which will run on the central MAHLE gateway system.
Later, the procurement hub apps may also be moved to the central gateway system.
The workflow logic itself would not be affected by this change.
The MIAM system (MAHLE Identity and Access Management) will be used as a data
source for user master and (extracts of) HR data, like manager and cost center
assignment. This information will be used as the central data source to find
approvers assigned to specific roles within the company.
Once the requisition is approved in the hub, it will be transferred to the
corresponding backend system, which could be either a SAP ERP or SAP S/4HANA
system (planned for later stages). Here the requisition(s) will be consolidated and
converted to purchase orders.
Next, the created ERP order will be blocked and uploaded to the hub for approval.
Once this is done, the ERP order will finally be released in both hub and backend and
sent to the supplier. In order to activate central purchase order approval,
additional settings are needed on ERP side that are described in chapter 4.3.6.

4.2 Workflow Framework

The recommended framework for implementation of procurement workflows in S4 is

the so-called “Flexible Workflow”. However, there are other options that should be
considered when doing a new implementation: Release Strategy (originating from
ERP MM) and Cloud Workflow (based on SAP Cloud Platform).
The table below displays the main features of these options along with their
advantages and disadvantages.
Release Strategy Flexible Workflow Cloud Workflow

Descriptio Role-based release of New default workflow Execute workflow on SAP

n documents taken over framework in S/4HANA Cloud Platform
from ERP MM

Prerequisi Maintenance of roles, Activation of corresponding SCP License

tes classes and Fiori apps
SAP Cloud Connector
characteristics
Customizing
Setup of workflow process
Development of Extensions
Development of
integration components

Advantage Stable and well-proven Well integrated into S4 Flexible flow-chart based
s tooling
Also used for other modules
(FI, SD, PLM) Can also be used for non-
SAP applications
Recommended procurement
workflow framework by SAP

Disadvant Necessary customizing Does not have the complete SCP license needed
ages can get very extensive feature set of other
No integration into S4
procurement solutions (e.g.

MAHLE International GmbH,

Stuttgart
Project MORE
 47

Limited options for SAP SRM) (yet) delivered by SAP (yet)

extensions
Extensions needed to cover Extensive custom
May become obsolete in all requirements developments needed for
later S4 releases integration and UIs

Limited SAP support for

the workflow logic

Not recommended by SAP

for S4 procurement
workflows at the moment

Our recommendation is to use the flexible workflow framework for the workflow
implementations in S4 (purchase requisition and central purchase order workflow),
because it provides most of the basic features required to implement a procurement
workflow in release 1809. Missing parts can be added as custom developments (see
the following chapters for details).
As the framework will be enhanced by SAP in the upcoming releases, some custom
extensions could be migrated to standard code later on.
Using the release strategy is no future-proof option, as there will be no new features
added by SAP and it may become obsolete in future S4 releases.
The cloud workflow would require extensive development work for integration into
the S4 procurement processes, because no content is delivered by SAP at the
moment.

For the implementation of the Procurement Hub, it was decided to use the flexible
workflow framework.

4.3 Customizing

4.3.1 Activation of Workflow Framework

The activation of the flexible (scenario-based) workflow framework is done on

document type level for purchase requisitions by activating the flag “Scenario-based
Workflow”. The flag “Overall Release” has to be set too in order to activate the
header-based approval.

MAHLE International GmbH,

Stuttgart
Project MORE
 48

The activation is stored in table T161 that is used to define document types for all
local purchasing documents (PRs, POs, RFQs and Contracts):

For central (uploaded) purchase orders, no customizing needs to be done in the hub
system. The workflow needs to be activated in the backend as described in chapter
4.3.6.

4.3.2 Activation of Workflow Scenario

A scenario (= workflow template) defines the available start criteria and approver
determination rules, whereas a workflow is a concrete instance of such a template.
Each scenario needs to be activated before workflows can be configured in the
corresponding Fiori apps.

MAHLE International GmbH,

Stuttgart
Project MORE
 49

The following scenarios are delivered by SAP for purchase requisition and order
approval:
Scenario Description

WS00800 Purchase Requisition (Header-

157 based)

WS00800 Purchase Requisition (Item-

173 based)

WS00800 Purchase Order (Local)

238

WS00800 Purchase Order (Central Hub

333 Approval)

Scenarios starting with WS9* are custom scenarios which are generated with a
sequential ID on creation.

MAHLE International GmbH,

Stuttgart
Project MORE
 50

In case a custom scenario was created (see chapter 4.4.1), the original SAP scenario
has to be deactivated in this table. Otherwise, the event linkage cannot be
deactivated permanently later on.

4.3.3 Definition of Approval Steps

The following apps in the section “Purchasing Configuration” can be used to

configure flexible workflows in the Procurement Hub:

After starting the app relevant for the business document you want to process, all
customized workflows will be shown. If multiple scenarios are activated for the
document, make sure the correct scenario is selected in the drop-down:

Multiple workflows can be defined for a business document, which are evaluated in
the specified order. It is also possible to restrict the workflow execution on a specific
period. This can be useful to implement a smooth transition to a new workflow.

After providing name, description and validity period of the workflow, the start
criteria can be defined (the available values are defined by the scenario).

MAHLE International GmbH,

Stuttgart
Project MORE
 51

The workflow will only be activated when all the criteria are met. As only one central
workflow based on the ASG is used at MAHLE, the preconditions are not used on
workflow level.
In the area below the preconditions, the workflow steps are defined. An arbitrary
number of steps can be added, each with its own start conditions and approver
determination rule.

Detail view of a workflow step:

MAHLE International GmbH,

Stuttgart
Project MORE
 52

The approver (recipient) of a workflow step can either be assigned directly (SAP user
ID) or determined based on a rule as defined in the scenario.
As a rule can resolve to multiple approvers, it is also possible to specify whether only
one user of the set of possible approvers needs to decide on the document or all of
them. In the latter case, they all will receive a workitem in parallel and the step will
only be completed once all user have made a decision.
The maintenance of the step start conditions is identical to the one for the whole
workflow. Custom start conditions were added for each workflow step of the MAHLE
scenario. These conditions resolve to method calls later on.
Lastly, it can be specified how the workflow should cope with the rejection of the
specific step.
After all conditions and steps have been specified, the workflow can be saved and
activated. Please be aware, that a workflow cannot be changed after it was activated
once. In this case, a copy needs to be created.

MAHLE International GmbH,

Stuttgart
Project MORE
 53

4.3.4 Maintenance of Approver Determination Rules

SAP provides the Business Rule Framework Plus (BRFplus) for maintenance of custom
rules. This is a flexible alternative to storing and evaluating the necessary rule data
in custom tables.
As mentioned in note 2291465, BRFplus is the successor of BRF that is declared
obsolete with S/4HANA.
A function will be created in BRFplus for each approval step, which maps the
document data to the responsible SAP users and also checks whether a step should
be executed at all.
Example:

Various expression types like decision tables and trees, database lookups and
function calls can be used to maintain the rules:

MAHLE International GmbH,

Stuttgart
Project MORE
 54

The necessary expressions to access local as well as centrally provided data (MIAM
interface, see chapter 3.2.1) will be created and can be reused in several approval
steps. Simulation and tracing of business rules is also available as a feature of
BRFplus.

4.3.5 Automatic Creation of Purchase Orders for Requisitions from Hub (Backend)

The conversion of incoming hub requisitions into purchase orders can be done
automatically in the backend system under the following conditions:

- All mandatory data is present in the requirement (e.g. supplier and account
assignment)
- Flag “Automatic Purchase Order” is set in the vendor master record (in the
backend)

- The automatic order conversion was activated for hub requirements in the
following customizing node:

MAHLE International GmbH,

Stuttgart
Project MORE
 55

4.3.6 Activation of Central Purchase Order Workflow (Backend)

SAP delivers workflow templates and integration services for the central approval of
ERP respectively S/4HANA purchase orders within the Procurement Hub.
The following customizing is available on backend side to activate the central
purchase order approval:

It can be activated based on the following criteria:

- Document Type
- Purchasing Organization
- Purchasing Group
- Company Code

MAHLE International GmbH,

Stuttgart
Project MORE
 56

If a matching entry is found during creation of a purchase order, the status EKKO-
PROCSTAT is set to “26” (external approval) which triggers the central approval after
uploading the document to the hub.
In order to block the backend order until the approval is done, a dummy release
strategy has to be implemented for the relevant documents, which will be completed
after approval within the hub (see chapter 4.3.7 for details).

The start criteria for the release strategy has to be synchronized to the settings
made in customizing described above.

MAHLE International GmbH,

Stuttgart
Project MORE
 57

4.3.7 Dummy Release Strategy (Backend)

This is a sample release strategy, which can be implemented on backend side to

block orders while they are processed in the hub workflow.
Start transaction SPRO and navigate to the following customizing nodes:

Create characteristics and a class, containing all relevant criteria to select the hub
orders (e.g. order type):

Create the following dummy release strategy:

MAHLE International GmbH,

Stuttgart
Project MORE
 58

MAHLE International GmbH,

Stuttgart
Project MORE
 59

After the release strategy has been implemented, orders will be blocked as long as
the release in the hub is not done.

4.3.8 Maintenance of Mail Templates

As the mail templates delivered with S/4HANA only support placeholders based on
flat structures, it was decided to use SO10 texts for storing custom mail templates.
With this solution, a higher flexibility regarding the mail content can be achieved
(e.g. generating item overview tables).

MAHLE International GmbH,

Stuttgart
Project MORE
 60

A class framework will be provided for using these mail templates. Common
functionality like sending the mail, generating logon links and doing basic
replacement will be provided by a base class. For each specific mail a dedicated mail
class will be derived which only provides special replacements and functionality on
top of the base classes implementation.

4.4 Custom Developments

The following subchapters describe a general solution approach for custom

extensions that are necessary to meet the requirements of MAHLE. For some points,
also a proof of concept was created which can be used for reference.
Please be aware, that the final MAHLE specific solution will be described in the
corresponding technical specifications.

4.4.1 Creation of Custom Workflow Scenarios

The workflow scenarios delivered by SAP only support a fixed set of start criteria and
approver determination rules. To extend these, a custom scenario can be created
and adjusted as needed. This scenario then replaces the SAP scenario at runtime.
This chapter describes the steps needed to create a custom scenario and attach it to
the business object (purchase requisition in this example). The process of adding
new start criteria and agent rules to the template is depicted in the following
chapters.
Start transaction SWDD_SCENARIO.
Open the source scenario, in this case WS00800157 (Header-based purchase
requisition approval):

MAHLE International GmbH,

Stuttgart
Project MORE
 61

Select “Save as…” from the menu:

Specify an abbreviation and name of the custom template:

The custom scenario will be displayed now and can be adjusted as needed:

MAHLE International GmbH,

Stuttgart
Project MORE
 62

Connect the custom scenario to the workflow start event:

Activate the scenario.

Start transaction SWE2.
Deactivate linkage to original template (filter on event TRIGGER_WORKFLOW):

Start transaction SM30 and open view V_SWF_FLEX_SCACT:

Deactivate the original SAP workflow scenario:

MAHLE International GmbH,

Stuttgart
Project MORE
 63

When using transaction SWDD_SCENARIO to copy the scenario, table entries in

SWF_FLEX_SCREG and SWF_FLEX_SCACT are created automatically for the new
scenario.
The following customizing has to be maintained to provide the action buttons
“Approve” and “Reject” within “My Inbox” for the custom scenario:

The “comment mandatory” checkbox should be activated for the action “Reject”, so
that the approver is forced to provide a comment on why he is rejecting the
document:

For handling the actions, an implementation of BADI

/IWWRK/BADI_WF_BEFORE_UPD_IB needs to be created and connected to the
custom scenario via its filter values. The implemented class delivered by SAP can be
reused.

MAHLE International GmbH,

Stuttgart
Project MORE
 64

MAHLE International GmbH,

Stuttgart
Project MORE
 65

In order to integrate the custom workflow scenario into the App “Manage Workflows
for Purchase Requisitions”, it needs to be added via Fiori Launchpad customizing
(client-specific, transaction FLPD_CUST) or configuration (cross-client, transaction
FLPD_CONF).
First, assign a transport request (optional):

Search for the “Manage Workflow” tiles in the “Purchasing Configuration” catalog:

MAHLE International GmbH,

Stuttgart
Project MORE
 66

Add the custom scenario to the navigation parameters:

The custom workflow scenario is now shown in the configuration App:

4.4.1.1 Additional Start Criteria for Approval Steps

The following chapters describe the necessary steps to implement additional start
criteria and agent determinations based on a generic customer field example. At
MAHLE, the checks and agent determination will be done based on the ASG rules.
First, the business object for purchase requisitions is extended to include a method
for checking whether a value is present in customer field of any item.
This is used to check, whether the ad-hoc step will be executed.
Start transaction SWO1 and create a new subtype for business object BUS2105001:

MAHLE International GmbH,

Stuttgart
Project MORE
 67

Add a new method for approval criteria evaluation:

MAHLE International GmbH,

Stuttgart
Project MORE
 68

MAHLE International GmbH,

Stuttgart
Project MORE
 69

Final result:

Start transaction SWDD_SCENARIO, select the custom scenario and open the
flexible block:

Create new records in the tab “Conditions” (this is what is shown in the drop-down of
the configuration app later on):

MAHLE International GmbH,

Stuttgart
Project MORE
 70

Add one or more parameters, the user can fill in the app:

Connect the parameters with fields or functions of the business object by specifying
conditions:

MAHLE International GmbH,

Stuttgart
Project MORE
 71

Now the custom criteria can be used as preconditions in the Fiori App:

MAHLE International GmbH,

Stuttgart
Project MORE
 72

Update 14.03.2019:
As the workflow for central purchase orders is class-based, no classic business object
exists for which a subtype could be created.
Therefore, a different approach for implementing the custom start criteria was
chosen: A custom utility class was added to the workflow container that connects the
conditions of the workflow scenario to the workflow class framework. Please see
chapter 7.2.2.1 for technical details.
In order to have a common approach for all business documents, the purchase
requisition workflow was extended in the same way. No business object subtype was
created in the MAHLE system.

4.4.1.2 Approver Determination

Please follow the steps below in order to add a new dedicated agent rule to a custom
workflow scenario. The benefit of this approach in comparison to using BADI
MMPUR_WORKFLOW_AGENTS_V2 is that it is possible to create a dedicated function
for each workflow step. This helps to determine which step is currently being
processed. The BADI only provides a list of the last approvers without any detailed
information on the current and past steps.
Start transaction SWDD_SCENARIO, open the custom workflow scenario and create
a new rule:

MAHLE International GmbH,

Stuttgart
Project MORE
 73

Create a copy of Function MMPUR_WFL_BADI_AGENT within the customer namespace

and adjust the code to determine the approval agents based on your custom logic
(e.g. call to BRFplus)

Assign the function to the new rule:

Add the rule to the agent rules of the flexible workflow block:
MAHLE International GmbH,
Stuttgart
Project MORE
 74

Maintain the binding from the workflow container to the rule container (can be used
as “import parameters”):

Now the new agent rule can be selected in the “Manage Workflows” App:

MAHLE International GmbH,

Stuttgart
Project MORE
 75

4.4.2 Adjustments to Standard UIs

In relation to the document’s workflow status some fields may have to be disabled
(not in scope for MAHLE release 1).
For the Fiori Apps this can be done using the extensibility options provided by the
App. Please refer to the documentation of the specific App for details:
https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/#/homePage
For UI adjustments in classical SAPGUI transactions, the available customizing and
the following BADIs can be used:

- ME_PROCESS_REQ_CUST for Purchase Requisitions

- ME_PROCESS_PO_CUST for Purchase Orders (in the backend system)

The screen customizing can be found in the following SPRO nodes:

4.4.3 Change fields in Workflow / Workflow Restart

For the first release, it was decided to use the standard restart logic for both
purchase requisitions and orders.

Changes that are made within the workflow will be considered in the evaluation of
future workflow steps.

MAHLE International GmbH,

Stuttgart
Project MORE
 76

For example, when an ad-hoc approver is added to the customer field within the
workflow, the corresponding workflow step will be become active.

4.4.3.1 Purchase Requisition

The fields which triggering a workflow restart for purchase requisitions are described
in the following note: https://launchpad.support.sap.com/#/notes/0002665086
The fields for evaluating the workflow restart are hard-coded without any extension
option via BADI or User Exit. An enhancement could be added to method
CL_MM_PUR_APPROVAL->CHECK_FOR_RESTART to implement customer logic.

4.4.3.2 Purchase Order

Per default, any change to the purchase order in the backend that is uploaded to the
hub will trigger a workflow restart.
In order to mitigate this, an Enhancement will be created that checks the document
on relevant changes before restarting the workflow.

4.4.4 Attachment Display in “My Inbox” for PRs

The display of documents attached to purchase requisitions is normally provided by

the SAP implementation of BADI WF_ATTACHMENT_PROVIDER (class
CL_MM_PUR_PR_WFL_ATTACH_BADI).
As the selection is done on CDS view i_purchasereqnitem, it does currently not work
for requisitions created within the hub (also see 3.3.2). As long as no fix is provided
by SAP, a new BADI implementation can be created which directly selects on table
EBAN instead of the CDS view.

MAHLE International GmbH,

Stuttgart
Project MORE
 77

4.4.5 Reminder / Escalation Process

The sending of reminder and escalation mails on overdue approval steps will be
implemented as a custom report, which will be scheduled to run once a day. The
deadline-monitoring feature of the SAP Business Workflow is not available for the
flexible workflow framework in release 1809.
The workitem selection will be done based on the customizing table as described in
chapter 3.4.4.
The mail text will be defined as a mail template (see chapter 4.3.6 for details).

4.4.6 Workflow Notifications

SAP provides a default mail template to notify users on workitems assigned to them:

MAHLE International GmbH,

Stuttgart
Project MORE
 78

As this mail lacks information on the document, it was decided to send the
notifications using a custom report. The workflow reminder report described in
chapter 4.4.5 already processes purchasing related workitems, so the notification
logic can also be integrated without causing much additional effort.

4.4.7 Info Message on Workflow Restart

The info message as described below will not be implemented in the first release. A
re-evaluation will be done during the pilot phase.

SAP provides a set of BADIs to implement document checks and display of custom
warning / error messages:

- MM_PUR_S4_SSPPR_CHK_DRAFT_ITEM: Implement checks on purchase

requisition drafts (created in SSP app but not yet ordered)
- MM_PUR_S4_PR_CHECK: Implement checks on purchase requisitions after draft
status

As the “running workflow” message should be displayed for the requester, it will be
implemented in the first BADI. A drawback of the BADI is that it does not provide
information on the documents workflow status and no document ID that could be
used to read the required data.
Therefore, an enhancement was created at the end of method
CL_MMPUR_PUR_V_BADI_ITM_CHECK->MAP_BADI_FIELDS that stores the complete
item record for later use in the check:

Then the check can be implemented as needed:

MAHLE International GmbH,

Stuttgart
Project MORE
 79

4.4.8 Filter PR Items in “My Inbox”

Additional estimated effort: 3 days

When using a header-based workflow, all items are displayed to the approver in the
app “My Inbox”. In order to provide a better overview on the items he is responsible
for, the following extension could be applied:

- Create a new DB table for storing the responsibility on item level. The
following fields are needed:
o PR and item number
o User ID
o ID of the workflow step
- When determining the approvers in the workflow rules, the item-level
assignment needs to be stored in the table
- The management of the table entries should be done using a central class
which needs to be integrated into the approver determination of each
approval step
- Create a copy of CDS views C_PurRequisitionFs and C_PurRequisitionItemFs
and add a WHERE condition which filters out the items not relevant for the
approver based on the custom table described above

MAHLE International GmbH,

Stuttgart
Project MORE
 80

- Create a new OData service based on the custom CDS view in SEGW
- Activate OData service in /IWFND/MAINT_SERVICE on the gateway system
- Replace the OData service for task TS00800547 in SWFVISU with the custom
service

The described extension is only applied to the app “My Inbox”. It does not filter any
items in the “Manage PR” apps or the classical SAPGUI transactions like ME52N.

4.5 Outlook on Takeover into the S4 Template System

Prerequisite for taking over most of the hub developments into the S4 template is
that the template is also based on release S4 1809 (or later).

Most of the workflow logic is independent from the deployed scenario (S4
procurement hub vs. S4 standalone) so most of the custom developments can be
reused, too.
An exception is the PO workflow, which is utilizing different workflow scenarios in
Hub (WS00800333) and Standalone (WS00800238) deployment. Nevertheless, it is
recommend to maintain all adjustments to the workflow scenarios centrally in the
hub system (see general approach below).
The following approach is recommend to reuse as much code as possible between
the hub and template system:

- All workflow related developments should be put into a dedicated package

(custom workflow templates, BADI implementations, Enhancement
implementations) on the hub. These developments can be imported to S4
backend systems (central code base).
- The data for the approver determination should be maintained centrally. It is
suggested that all necessary data (MIAM connection, custom tables, etc.) is
maintained in the hub. Execution of the approver determination is done via
RFC calls from each S4 system to the hub (single source of truth).
- Only the customizing of the workflow steps is done locally in each S4 system
(see chapter 4.3).

Alternatively, a transport would not be necessary if all purchasing workflows could be

done within the Procurement Hub (to be decided).

MAHLE International GmbH,

Stuttgart
Project MORE
 81

5 Outlook on Next Releases

The intention of the first release is to deliver a solid foundation for workflows within
the Procurement Hub. Based on the first feedback, additional solutions can be
implemented for further improving the user experience.
The following extensions will be evaluated for upcoming releases:

- Implementation of ad hoc approver functionality

- View for displaying PO details in inbox (if not delivered by SAP via OSS)
- Handling for requisitions with “Urgent” indicator (shortened workflow,
additional notifications, shorter reminder timeframes)
- Additional approval step for “Buy on Behalf” (technical evaluation in
interaction with Ariba Guided Buying)
- Mail notifications on rejection
- Enable working on requisitions in status “In Approval” with the App “Manage
Purchase Requisitions” for the purchasers (instead of opening several
workitems)
- Implementation of “real” approval preview
- Reporting on technical workflow logs for audit
- Hide attachment tab in inbox or display workflow attachments in the business
transactions
- Push notifications on iOS
- Central maintenance of ASG
- Enable maintenance of dedicated notification and escalation settings for each
approval step (in order to send reminders later to purchasers)
- Addition of further optional approval steps for central purchase orders
- UI control for documents in approval (restrict fields which can be changed)

The following Enhancements were rejected by the Governance Board for the first
release and will be re-evaluated during the pilot phase:

- Warning message on possible workflow restart (as described in chapter 4.4.7)

- Custom evaluation of workflow restart criteria for purchase requisitions and
orders (as described in chapter 4.4.3)

MAHLE International GmbH,

Stuttgart
Project MORE
 82

6 Impact Estimation
6.1 Global Template

6.2 Business Processes

6.3 Testing

Test cases:

MAHLE International GmbH,

Stuttgart
Project MORE
 83

7 Implementation Details
7.1 Customizing

7.1.1 Basic Workflow Setup

In transaction SWU3, the prefix for custom workflow templates was maintained:

This prefix will be applied to all custom workflow scenarios and only has to be set
once in the development system.

7.1.2 Activation of Workflow Framework

The scenario-based workflow was activated for the following business document
types:
Purchase YAR (via hub customizing as described in
Requisition 4.3.1)

Purchase Order YAR (via backend customizing as

described in 4.3.6)

7.1.3 Activation of Workflow Scenario

Both custom workflow scenarios have been activated as described in chapter 4.3.2:

MAHLE International GmbH,

Stuttgart
Project MORE
 84

7.1.4 Activation of Apps for Workflow Management

Transaction SICF – Activated the following services:

- NW_APS_BPM_LIB
- NW_APS_BPM_SWE
- FDT_WD_WORKBENCH (Maintenance of BRFplus rules)
- CA_FIORI_INBOX (App “My Inbox”)

Transaction /IWFND/MAINT_SERVICE – The following OData services were

activated:

- SWF_FLEX_SCENARIO_SRV
- /IWPGW/TASKPROCESSING

The custom workflow scenarios were added to the selection of the “Manage
workflows for …” apps as follows:

- Open Fiori catalog customizing by calling transaction /UI2/FLPD_CUST

- Search for catalog SAP_TC_PRC_COMMON
- Locate and open the tiles for managing PR and PO workflows

MAHLE International GmbH,

Stuttgart
Project MORE
 85

- Add the corresponding custom scenario to the parameter list of the navigation

7.1.5 Settings for App “My Inbox”

Configuration of system alias for workitem retrieval in “My Inbox”:

The available actions (Approve, Reject) were configured for the tasks of the custom
scenarios:

MAHLE International GmbH,

Stuttgart
Project MORE
 86

7.1.6 Approver Determination Rules

Main parts of the approver determination can be influenced by changing business

rules in transaction BRF+.
Three applications were created to store the rules (similar to the package structure
for development objects).

Name Description

/MAHLE/0355_APPROVAL Document-independent rules (including ASG and

exceptions)

/MAHLE/ Specific rules for approval of PRs

0356_APPROVAL_PR

/MAHLE/ Specific rules for approval of central POs

0357_APPROVAL_CPO

The objects relevant for ongoing maintenance (decision tables) are described in the
following chapters. For easier access, they have been added to the catalog view
ASG_CATALOG, which hides all other objects:

MAHLE International GmbH,

Stuttgart
Project MORE
 87

7.1.6.1 General Notes on Decision Tables

The usage of a decision table is similar to a customizing table with the following
major differences:

- Entries are evaluated from top to bottom and the first match is returned. This
means the list has to be sorted from specific to generic entries with the most
generic record being at the end.
- Excel import and export is supported out of the box
- Simulation is possible (check which record will be returned for an specific
input)

7.1.6.2 ASG (Business Rules)

For the first release, a local representation of the Approval and Signature Guidelines
(ASG) was created as a decision table.
In the first columns, the document data is specified which should be checked for a
match:

At the end of the table, the needed business roles are maintained for all approval
steps:

The table is used to find the necessary business roles for approval based on the
document’s data (valid for both PR and CPO).
If no value is maintained in one of the business role columns, this means that the
corresponding workflow step will be skipped.
All changes to the table will be recorded in a standard customizing request.

MAHLE International GmbH,

Stuttgart
Project MORE
 88

7.1.6.3 Approver Determination

As long as the MIAM interface is not in place, the assignment of users to business
roles is done within the hub in decision table ASG_APPROVER.

Higher codes include the authority to approve for lower code. For example, if code
700 is assigned to a user he is also authorized to approve code 500.
Maintenance of the table can be done locally without a transport request.

7.1.6.4 Optional Approvers

Decision table ASG_OPTIONAL can be used to activate optional workflow steps within
the PR and CPO workflow for special cases. In this table, the user IDs are assigned
directly (not via business role codes).
Each of the OPTIONAL_APPROVER_* columns corresponds to a specific optional step
within the PR / CPO workflow (see chapter 3.2 for an overview) where additional
approvers can be inserted.

In this table, it is possible to add multiple rows with the same criteria in order to add
multiple optional approvers.
Maintenance of the table can be done locally without a transport request.

7.1.6.5 Exceptions to ASG

This decision table is also executed within the approver determination and can be
used to overwrite the approver returned by MIAM (resp. the local approver determed
based on ASG_APPROVER in release 1) for special processes.
In the first columns, the document data has to be specified on which the exception
has to be applied:

In the next fields, the business role that should be replaced along with the target
approver needs to be specified:

MAHLE International GmbH,

Stuttgart
Project MORE
 89

Maintenance of the table can be done locally without a transport request.

7.1.7 Configuration of Workflow Mail Notifications / Reminders

The frequency and text of workflow notification and reminder mails can be
configured in table /MAHLE/0355_0001:

Both the initial notification on a new workitem (= level 1) as well as following

escalations (= level 2 and higher) are maintained in this table.
The task and processing class are specific to the business document (PR =
“TS00800547”, CPO = “TS00800600”) and can simply be copied for new entries.
Threshold defines the time in days after which the level becomes active (all previous
levels will be inactive then) and the repetition time causes the mail to be resent after
a specific amount of days.
The responsible approver and his manager (as defined by the MIAM BOSSID) can be
set as possible mail recipients.
Finally, a text template can be defined per level, which points to a standard text
defined in transaction SO10.

The mail text can be freely created using HTML for formatting. IDs enclosed in &&
are used as placeholders and will be replaced by the runtime class specified in the
customizing table mentioned above.
There are some generic IDs that can be used for any mail and document-specific IDs,
which are defined by the runtime class.

MAHLE International GmbH,

Stuttgart
Project MORE
 90

Overview of generic IDs:

ID Description

MV_HTML_MAIL_BEGI Generate frame of HTML mail (mandatory)

N

MV_HTML_MAIL_END Generate frame of HTML mail (mandatory)

ITEM_DETAILS Generate an overview list of the document’s items

Needs to be implemented by method GET_ITEM_DETAILS in the runtime
class

LOGON_LINK Generate a link to the App “My Inbox” (or another target by overwriting
GET_LOGON_LINK in the runtime class)

DOCUMENT_CREATO Insert full name of the business document’s creator

R Needs to be implemented by method GET_DOCUMENT_CREATOR_NAME in
the runtime class

In addition, any public (read-only) attribute of the runtime class can be used as a
document-specific ID.
Example for PRs:

7.2 Development

7.2.1 Class Overview

One of the main targets of the implementation was efficient sharing of common code
between workflow steps and providing a clean interface to integrate the custom code
into the flexible workflow framework. In order to achieve this, several class
frameworks were implemented which are described in more detail in the following
chapters. Shared logic is implemented in the general or document-specific base class
and only step specific details need to be implemented or overwritten by the workflow
step implementations.

7.2.1.1 Approval Framework

A class framework has been implemented to build the foundation of all workflow
steps. The basic idea is, to provide a dedicated class per workflow step, which
inherits document-specific and generic code from special base classes. This way,
code can be reused effectively.
Basic structure of a workflow step class that is the central point for all logic related to
this specific step:

MAHLE International GmbH,

Stuttgart
Project MORE
 91

Some additional development objects are needed to integrate the workflow step
class into the workflow scenario as defined in transaction SWDD_SCENARIO.
Overview on the main classes of the framework:

Figure 5 - Workflow Step Framework

The general process flow for checking a workflow step’s start conditions and
approver determination are depicted in the following charts.

MAHLE International GmbH,

Stuttgart
Project MORE
 92

Figure 6 - Process flow for checking start criteria on the example of “Internal Approval #1”

Figure 7 - Process flow for approver determination on the example of “Internal Approval
#1”

7.2.1.2 Mail Framework

Basic overview on the mail and notification framework:

MAHLE International GmbH,

Stuttgart
Project MORE
 93

Figure 8 - Mail and Notification Framework

The basic structure is similar to the one of the workflow framework. The common
base class representing any kind of mail is extended by business document specific
subclasses. Finally, a specialized class is created for each specific mail.
Program /MAHLE/0355_WFL_NOTIFICATIONS has to be scheduled to run once a
day as a job to collect all overdue workitems and send the appropriate mails.

Figure 9 - Basic process flow of sending a notification mail for a PR

MAHLE International GmbH,

Stuttgart
Project MORE
 94

7.2.2 Workflow Scenarios

A custom workflow scenario was created for PR and PO approval based on the
following SAP templates in transaction SWDD_SCENARIO:
SAP Custom
Template Template

PR Approval (Header) WS0080015 WS90000001

7

Central PO Approval WS0080033 WS90000003

(Header) 3

MAHLE International GmbH,

Stuttgart
Project MORE
 95

Most of the logic for implementing a flexible workflow is generated from the flexible
block:

This includes the start criteria available in the “Manage Workflows for …” apps
(custom ones are highlighted):

MAHLE International GmbH,

Stuttgart
Project MORE
 96

As well as the approver determination rules:

Both extension points are described in more detail in the following chapters.

7.2.2.1 Start Criteria

The main reason why custom start criteria are needed are special circumstances that
require a workflow step to be skipped. For example:

 Approver is identical to the document’s requester

 Approval step is not needed according to ASG

Both criteria cannot be covered using SAP start conditions. Just returning an empty
approver list during approver determination is also not sufficient to skip a step, as
this will result in a workflow error.
In order to call the main workflow step class when executing a start condition check,
a special utility class was created and added to the program exists of the workflow
scenarios:

MAHLE International GmbH,

Stuttgart
Project MORE
 97

The utility class is called to fill a special structure in the scenario’s workflow
container that stores the activation status of each step:

Finally, the condition value of the structure is connected to the start condition as
defined in the flexible block:

MAHLE International GmbH,

Stuttgart
Project MORE
 98

Internally, the utility class forwards the call to the main workflow class:

7.2.2.2 Approver Determination

Custom approver determination rules are necessary because the BADI provided by
SAP makes it hard to determine which workflow step is currently being processed.
The same BADI implementation is called for every step. A list of previous approvers
is provided as a guide, but this can be difficult to interpret especially when
substitutes are involved in the approval process.
The integration between the approver determination of the workflow scenario and
the workflow class is provided by rules. These rules can be access via the menu
within SWDD_SCENARIO:

The rule calls a function module, which in turn forwards the call to the workflow step
class:

MAHLE International GmbH,

Stuttgart
Project MORE
 99

7.2.3 Business Rules

Business rules are maintained in transaction BRF+ and are executed in order to
determine if a step should be executed and who is assigned as the responsible
approver.
Several rules, calculations and decision tables are involved in the approver
determination. An example is shown in the following picture:

Figure 10 - Rough flow of the business rule execution for the workflow step “Internal
Approval #1”

7.2.4 Processing of Workitems

In order to process the decisions made on the custom scenarios, two

implementations of BADI /IWWRK/BADI_WF_BEFORE_UPD_IB have been created
and connected to the corresponding workflow task.

MAHLE International GmbH,

Stuttgart
Project MORE
 100

7.2.5 Tool Classes

Some additional classes provide utility functions that can be used by all workflow
steps.
Class Description

/MAHLE/CL_0355_BRF_EXIT Enable local editing of specific decision tables in BRF+

(without transport request)

/MAHLE/ Determination of the responsible user for a specific accounting

CL_0355_WFL_ACCOUNTING object via RFC backend calls

MAHLE International GmbH,

Stuttgart
Project MORE
 101

7.3 Miscellaneous

7.3.1 BRFplus Trace

BRFplus provides the possibility to create a trace for all steps of rule evaluation. In
order to activate the trace for a specific user as needed, a new user parameter was
created:

This way, tracing can be activated on user level and without decreasing the
performance for other users:

The trace results can be accessed via transaction BRF+:

MAHLE International GmbH,

Stuttgart
Project MORE
 102

Expert mode needs to be activated in order to use the “Trace” option:

MAHLE International GmbH,

Stuttgart
Project MORE
 103

8 Related Documents

MAHLE International GmbH,

Stuttgart
Project MORE