Ciba Specialty Chemicals

Project Enterprise
Documentation - Workflow

Documentation of
PCT.005
Workflow for Purchase
Order Approval

1.1

Paper Chemicals

Ciba Specialty Chemicals

Version: 1.1,CURRENT
Status: open
Date:
January 9, 2007 3:45:03 AM GMT+05:30

1.1

Paper Chemicals

Project Enterprise
Functional Specification
Workflow

Document Information
General Information
Project Name

Project Enterprise

Document Location

Shared Folder

Associated Documentation

<Enter the related Business Process Documents (Process, Sub-Process, Gap, etc.>

Document History
Date

Name

Dept.

Change

Status

April 18th, 2006

Volker Sigg

Accenture

Document creation

Draft

Finalize open topics

Draft

Document creation

Draft

Approval (Signature for acceptance)

Business Owner

Name / Signature
Gerd Irion

IDC point of contact

Kumar Devaraju

Ciba point of contact

Jean Pierre Pawela

Date

Functional Specification Workflow Definition

Business Process Team

PCT

Business / Process
Owner

Gerd Irion

Functional Designer

Maurice Cruts

Complexity

Medium

Planned Start Date

January 1, 2005 1:00:00 PM EST

(Planned date for start of

Technical specification)

Planned End Date

February 28, 2006 1:00:00 PM EST

(Planned date of handover from

IDC after unit test)

11/02/2015

260089642.doc

Page 3 of 17

Project Enterprise
Functional Specification
Workflow

TABLE OF CONTENTS
1

OVERVIEW AND SUMMARY.............................................................................................................. 5

1.1
1.2

SUMMARY....................................................................................................................................... 5
WORKFLOW OVERVIEW................................................................................................................... 5

TECHNICAL DETAILS......................................................................................................................... 6
2.1
WORKFLOW CONTAINER.................................................................................................................. 6
2.2
BUSINESS OBJECT BUS2012.......................................................................................................... 8
2.2.1
Delegation..............................................................................................................................................8
2.2.2
Custom Attributes...................................................................................................................................8
2.2.3
Custom methods......................................................................................................................................9

DETAILED WORKFLOW DESCRIPTION..........................................................................................10

3.1
RELEASE STRATEGY S1 AND RELEASE STRATEGY S2.....................................................................11
3.2
RELEASE STRATEGY S3................................................................................................................. 13
3.2.1
Getting the superior to approve the PO...............................................................................................13
3.2.2
Approval of the PO...............................................................................................................................17

2/11/2015

260089642.doc

Page 4 of 17

Project Enterprise
Functional Specification
Workflow

1 Overview and Summary

1.1

Summary

The Workflow for Purchase Order Approval is designed to grant a fast and seamless approval
of posted purchase orders (PO)
When a PO gets posted in the ERP System the workflow starts and gives the PO to the
appropriate approver. This document describes the implementation of the workflow, the
technical settings and the coding.

1.2

Workflow Overview

For an overview of the workflow use transaction SWDD.

The Workflow Template Number for this workflow is WS99900001.
The Standard workflow (WS20000075) for PR approval needs to be deactivated
The workflow distinguish between 3 types of Release Strategies for the PO:
- Release Strategy S1 (PO is automatically created and its amount is greater than
50000 CHF)
- Release Strategy S2 (PO is manually created and its amount is between 50000 and
100000 CHF)
- Release Strategy S3 (PO is manually created and its amount is greater then 100000
CHF)
For every of the types there is a separate branch in the workflow.
The bulletpoints 3.1 3.3 describe these approval chains in detail.
These branches are generated by the step 4 Check release strategy.

2/11/2015

260089642.doc

Page 5 of 17

Project Enterprise
Functional Specification
Workflow

2 Technical details
2.1

Workflow Container

The workflow container gathers all necessary information needed for the workflow and for
the approval.
In following a description of the Workflow Container.

The elements which begin with an underscore are standard elements of every workflow
container and need no furter explanation.
a) PurchaseOrder:
This is the object the workflow is working with mainly.
Is referring to the business obect BUS2012, which is containing all data about the PO.
The BO is decribed in bullet point 2.2
b) ReleaseCode
refers to T16FC-FRGCO
The release code is given to the Relaese steps
c) ApprovedRejected
refers to the data dictionary type TEXT10.
This container element is used to store the text approved or rejected depending
on the release status of the PO
It is filled by a container operation
d) Approval_Manager
refers to WFSYST-AGENT
This is the agent for all approval steps, is filled with the userID of the appropriate
supervisor
e) Supervisor_eMail
refers to PA0105-USRID

2/11/2015

260089642.doc

Page 6 of 17

Project Enterprise
Functional Specification
Workflow
is filled by the task Get Superior with right approval level, contains the eMail
Adress of the Approval_Manager (Method gets it from the HR-Mini-Master Infotype
0105, Suptype 10)
f) Approvor_Rejector
refers to WFSYST-AGENT
contains the UserID of the user who approved or rejected the PO
g) Exception_Flag
refers to dictionary type CHAR1, is a flag which is set by a container operation if an
exception in the workflow occurs (missing data maintenance, for example no user
maintained for the manager or no user maintained for the project responsible person)
h) Data_OK_Flag
is not used in this workflow anymore

2.2

Business Object BUS2012

2.2.1 Delegation

2/11/2015

260089642.doc

Page 7 of 17

Project Enterprise
Functional Specification
Workflow
The BO BUS2012 is the Standard BO for Purchase Orders. In order to enhance this Business
Object with own coding and logic it is necessary to create a copy of it.
In this case this copy is called ZBUS2012. The ZBUS2012 inherits all attributes, methods and
events from his supertype BUS2012.
To make sure that everytime the BO BUS2012 is called also the logic of ZBUS2012 is called a
delegation of BUS2012 to ZBUS2012 is needed.
This is made in TA SWO1:

2.2.2 Custom Attributes

Custom Attributes are attributes of the BO which are not defined in the Standard delivery.
In CIBA and the BO ZBUS2012 we defined the following Custom Attributes:
a) CompanyCode:
refers to EKKO-BUKRS
the attribute gets the company code out of EKKO
b) Currency:
refers to EKKO-WAERS
the attribute gets the currency of the order
c) OverallNetValue:
refers to CEKKO-GNETW
is the overall net value of the order
d) CreatedBy
refers to EKKO-ERNAM
is the user who created the PO
2/11/2015

260089642.doc

Page 8 of 17

Project Enterprise
Functional Specification
Workflow

2.2.3 Custom methods

In CIBA and the BO ZBUS2012 we defined the following Custom Methods:
Method GetSupervisor:
Uses the function module `Z_Get_Superior`
(as described in TCHS_CUSTOM_DEVELOPMENT_WORKFLOWS) .
The method imports the needed import elements of the function module.
It gives back the User of the appropriate superior.
The function module writes all superior users of the creator in the table WFL_APPROVAL_TABLE_BADI.
For this workflow the method exports the userID with the highest Approval_Index into the task container.
(for details on the mentioned table and function module see
TCHS_CUSTOM_DEVELOPMENT_WORKFLOWS)

Method GetUnlimitedApprover:
Uses the function module `Z_MM_UNLIMITEDAPPROVER`
(as described in TCHS_CUSTOM_DEVELOPMENT_WORKFLOWS) .
The method imports the Plant and the Company Code.
It gives back the User which has unlimited approving rights and his eMail address.
This user is maintained in the custom table ZFUNLIMITAPPR (also described in
TCHS_CUSTOM_DEVELOPMENT_WORKFLOWS). The eMail is maintained in HR-Mini-Master.

3 Detailed Workflow description

Like mentioned in the beginning the workflow distinguishes between 3 types
of Release Strategies in the PO:
The decision which branch to take is checked in Step 4 of the workflow:

2/11/2015

260089642.doc

Page 9 of 17

Project Enterprise
Functional Specification
Workflow

For every release strategy a separate branch is generated:

These 3 branches are explained below.

2/11/2015

260089642.doc

Page 10 of 17

Project Enterprise
Functional Specification
Workflow

3.1

Release Strategy S1 and Release Strategy S2

The release strategy S1 is triggered when a
PO is automatically created and its amount is
greater than 50000 CHF.
The release strategy S2 is triggered when a
PO is manually created and its amount is
between 50000 and 100000 CHF
For both release strategy the same workflow
logic is applied.
In both cases the Purchase Order is given to
the User who is assigned to the Purchasing
group of the PO.
The picture shows the branch for release
strategy S1.
The Purchasing Group is a standard attribute
of the business object BUS2012 (Purchase
Order).

The assignment of the User to the

Purchasing Group is done in the transaction
PPSM as shown in the following picture:

2/11/2015

260089642.doc

Page 11 of 17

Project Enterprise
Functional Specification
Workflow
The workflow uses this assignment via a rule to determine the User who has to approve the
PR.
The rule in this case the rule 99900001 Get Purchasing Group:

The rule is using the purchasing group

and gives the user back to the workflow.
The workitem is sent to the found user
and he / she can approve or reject the
PO.
As the task TS20000166 is an
asynchronous task it needs a
terminating event.

As the task TS20000166 is an

asynchronous task it needs a
terminating event.
The configuration of the step
only allows to proceed with the
workflow when the PO is
rejected or it`s released.
Once the PO is released or
rejected the Workflow Initiator
gets a SAP notification about
the decision.
After these notifications the approval for a PO with release strategy S1 is done.

2/11/2015

260089642.doc

Page 12 of 17

Project Enterprise
Functional Specification
Workflow

3.2

Release Strategy S3

Release Strategy S3 is triggered when the PO is manually created and its amount is greater
then 100000 CHF. In this case the PO needs to be approve by a line supervisor with the right
approval level

3.2.1 Getting the superior to approve the PO

The picture shows the steps which are involved in the determination of the superior to
approve the PO.

The step Get Superior with right approval level (Step 41) contains the Task TS99900003.
This task contains the above described method GETSUPERVISOR.

2/11/2015

260089642.doc

Page 13 of 17

Project Enterprise
Functional Specification
Workflow
If the method finds a superior with the appropriate approval level and his / her eMail address
the outcome Supervisor found is taken. The exception flag is set to 0 (means no
errors, step 48)
If the supervisor is not maintained properly (no Supervisor maintained for creator of PO, no
eMail Adress maintained for one of the supervisors, no level maintained for one of the
supervisors) the method gives the error NO_DATA_MAINTAINED. If this error occurs the
outcome no data maintained is taken.
The exception flag is set to X (step 54) and the Workflow Intitiator
gets the following notification (step 72):
Dear Workflow User
you just created a PO.
No.: &PURCHASEORDER.PURCHASEORDER&
Unfortunately there is something wrong with the master data.
Please contact your HR representative to check the following options:
- Is your superiorchain maintained correctly ?
- Is your eMail Adress or the eMail adress of one of your superiors maintained correctly ?
- Is your Approval Level or the Approval level of one of your superiors maintained correctly ?
Yours faithfully,
Workflow System

After that a user decision is sent to the Workflow Initiator in which he decides weather the
data is maintained and the workflow can be continued or to keep the workitem and wait for
the maintenance. (step 77). The decision step looks like this after the execution in the SAP
inbox:

If the User clicks on Data is maintained now, go ahead! the workflow continues and loops
up again to check again if a supervisor can be found. More to the loop later.
If he/she clicks on Cancel and keep work item in inbox, the work item is kept in the inbox of
the user.
2/11/2015

260089642.doc

Page 14 of 17

Project Enterprise
Functional Specification
Workflow
The user can ask someone to maintain the data and if the data is maintained after a while
the user can execute the work item again an click on the Data is maintained now button.
If the order value is higher than the highest approval level value (maintained in table
ZMMT_PLIMIT) the method gives the exeption HIGHEST_APPROVAL_LEVEL_REACHED.
In this case the outcome highest_approval_level_reached is taken.
The exception flag is set to 0 (step 51) and the workflow enters the step Get unlimited
Approver of PR (step 57). This step contains the task TS99900004 which contains the above
described method GETUNLIMITEDAPPROVER.
The method determines the unlimited approver for the company code of the PR. It returns
the UserID and the eMail address of that user.
The unlimited approver is maintained in the table ZMMT_UNLIMITAPPR.
The exception flag which is set in every outcome is needed for the loop in which this section
is in.
The whole section is repeated if the exception flag is set to X (means, that there was an
error).
In order to get the right supervisor and eMail Adress after an error the workflow loops up
again and tries to determine the supervisor and the eMail. If there is no error anymore the
flag is set to 0 and the workflow is not looping up but continuing.
The following two pictures show the loop and the technical detail of the loop step (step

2/11/2015

260089642.doc

Page 15 of 17

Project Enterprise
Functional Specification
Workflow

3.2.2 Approval of the PO

After the loop section to determine the supervisor, the approval section follows:

2/11/2015

260089642.doc

Page 16 of 17

Project Enterprise
Functional Specification
Workflow

This section follows the same logic as the approval for Release Strategy S1 and S2.
The only difference is, that the user is not determined by a rule with the Purchasing group
but in the above described steps.

2/11/2015

260089642.doc

Page 17 of 17