This Wiki Page will show you how to Customize the ESS Leave Approval process using SAP Business Workflow.
We will configure the Leave Approval process with Standard Workflow Template WS12300111, which provides a single level of approval.
Additionally, we will also discuss the possibility of scaling this to a Workflow with multiple levels of approval.
Activating the Leave Workflow
As you would have already read on page Transactions and Reports in PT on ESS, the entire Leave Framework can be simulated via Transaction code PTARQ.
These steps should be followed in order to activate the Approval Workflow for Leaves.
- First, maintain Visualization Parameters for tasks of WS12300111 in SWFVISU .
The two Tasks of the Workflow, TS12300097 and TS12300116 are to be visualized to Java Webdynpro Applications.
If there is a Task TS12300104, this Task should be deleted according to SAP note 779075
I found this Wiki page on SWFVISU , which might be helpful if you require to customize and visualize your own tasks.
- Next, Activate Approval via Workflow for the leave types.
This can be done via PTARQ > Customizing > Employee Self-Service > Service-Specific Settings > Working Time > Leave Request > Processing Processes > Specify Processing Processes for Types of Leave > Define Absences/Processing Processes
( You can also reach the customizing setting from SPRO via SAP Customizing Implementation Guide > Personnel Management > Employee Self-Service > Service-Specific Settings > Working Time > Leave Request > Processing Processes > Specify Processing Processes for Types of Leave > Define Absences/Processing Processes )
These are the same tables like in the old ITS based version - and can also be reached over the customizing for the old ITS based version. However, the above path also provides the correct documentation.
Select or Add a Leave Type, then click then edit button/or double click it to go to the next screen which displays more parameters.
Check the box that says " Process Request using Workflow".
Once you check this option, 3 new parameters appear :
a. WF ID of New Request
b. WF ID of Cancellation Request
c. WF ID of Change Request
You should fill out the Workflow Template number "12300111" (or any custom workflow that you'd developed for the purpose) against each of these, ofcourse based on scenarios you would want to handle with the Workflow.
This allows us to define which actions use which workflow for a given Leave Type. If you keep one of the fields mentioned above empty, the standard workflow is taken - please fill all the fields all the time.
In case you do not want an approval for a special leave type, you may uncheck the checkbox 'Request Have To Be Approved'.
- Next, You should run/schedule the report RPTARQPOST to post the Approved Leaves (For Approved Leaves, PTREQ_HEADER-STATUS = APPROVED).
On successful execution, RPTARQPOST updates the Leave Infotypes with the approved Leave data.
Good to know stuff:
1. BADI PT_GEN_REQ can give you more control on the processing process like Filtering Agents, Starting the Workflow, etc.
Scaling the Workflow for Multiple Approval Levels
An object 'Req' of the CL_PT_REQ_WF_ATTRIBS is passed to the Workflow container when it is being triggered.
Note that 'Req' references the Persistent Object of the Leave Request. Any change to the Persistent Instance of the Request means that the change will be visible in 'Req'.
You can always reference the Persistent Instance of the Request by calling the method CL_PT_REQ_WF_ATTRIBS=>BI_PERSISTENT~FIND_BY_LPOR (Note that : LPOR-INSTID = REQUEST_ID).
To scale the Approval process to multiple levels, you should copy the existing template WS12300111 and modify the new template introducing steps for further levels of approval.
You would have noticed that once approved, the Request status would go from SENT to APPROVED. In the Workflow this would affect the value of REQ.STATUS.
We need to introduce a couple of steps to facilitate the next level Approval process via ESS.
Step 1. Reseting the Status to SENT
In WS12300111 this was the Status change that we checked for at Step 000158 ('Request Approved?'). Now, for the new template, if the outcome of this step is 'Approved',
we should re-set the status to SENT. Sample code for state transition from APPROVED to SENT is given below:
Step 2: Setting the Next Processor
After the Agent Determination for the Next Level of Approval, it is essential that you update the Request with this information.
The CL_PT_REQ_WF_ATTRIBS class has an Attribute called N_PROCESSOR which needs to be set so that this is visible in ESS.
The sample code to achieve this is given below :
The new Workflow Template can now have any number of Approvals with the above Step 1 and Step 2 being inserted after each approval (Task TS12300097) and only in case if there is another Level of Approval .
Do not forget to set this New Approver as the Agent for TS12300097 as well.
If you are new to PT on ESS, you should consider reading these pages on this Wiki:
- Getting Started in ESS
- Getting Started on PT in ESS
- Transactions and Reports in PT on ESS
- Leave Request Various Configuraton Steps
Got any problems with this solution? You can read related articles in the Forums on this:
- Issue with two level ESS leave request workflow
- Customization Done for 2 level approval of leave in ESS but Facing Problems
Author: Vimal Vidyadharan