This post is applicable to only those organizations where Organization structure is defined and No Manual selection of approver is given while applying Leave Request.
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.
These steps should be followed in order to activate the Approval Workflow for Leaves.
I found this Wiki page on SWFVISU , which might be helpful if you require to customize and visualize your own tasks.
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'.
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.
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:
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.
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
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. 2. When a Leave Request is created, an entry is created in the PTREQ_HEADER table. REQUEST_ID is the unique identifier for a Leave Request. 3. Actors (All agents involved with the request, like Owner, Initiaor, Next Processor, etc.) would have an entry in the Table PTREQ_ACTOR. If it does not exist, it will be created during the Leave Approval process (Refer Implementation of CA_PT_REQ_ACTOR->CA_PT_REQ_ACTOR) . 4. PTREQ_ITEMS and PTREQ_ATTABSDATA are other tables that contain data about the Leave Request. PTREQ_ITEMS can tell us if the Leave Request was New or a request for Change or Cancel. The Time data is recorded in PTREQ_ATTABSDATA |
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:
DATA: lcl_request type ref to if_pt_req_request. *-- Enqueue the request call function 'ENQUEUE_EPTREQ' exporting mode_ptreq_header = 'S' mandt = sy-mandt request_id = Request_id exceptions foreign_lock = 1 system_failure = 2 others = 3. if sy-subrc <> 0. message id sy-msgid type sy-msgty number sy-msgno with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. endif. *-- Get the Persistent Leave Object call method cl_pt_req_badi=>get_request exporting im_req_id = Request_id importing ex_request = lcl_request. *-- Initiate the State Transition to SENT call method cl_pt_req_badi=>initiate_state_transition exporting im_request = lcl_request im_event = cl_pt_req_const=>c_reqtrans_send importing ex_new_status = new_status. commit work and wait. *-- Dequeue call function 'DEQUEUE_EPTREQ' exporting mode_ptreq_header = 'S' request_id = Request_id.
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 :
*--Enqueue the request
callfunction'ENQUEUE_EPTREQ'
exporting
mode_ptreq_header='S'
mandt=sy-mandt
request_id=Request_id
exceptions
foreign_lock=1
system_failure=2
others=3.
*-- Get the request object instance
call method cl_pt_req_badi=>get_request
exporting
im_req_id =Request_ID
importing
ex_request = lcl_request.
call method lcl_request->set_next_processor
exporting
im_actor_type = 'P'
im_plvar = '01'
im_otype = 'P'
im_objid = NextApprover_PERNR. " PERNR of Next Approver
if sy-subrc = 0.
commit work and wait.
endif.
*-- Dequeue the request
callfunction'DEQUEUE_EPTREQ'
exporting
mode_ptreq_header='S'
request_id=Request_id.
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.
No comments:
Post a Comment