cancel
Showing results for 
Search instead for 
Did you mean: 

Anyway to change the req.status container in wf?

Former Member
0 Kudos

Dear all workflow expert,

Anyone knows how to change the req.status so that i can do a 2 level approval or anyone can suggest me a way to do it apart from what i did below?

Thanks

Regards,

Bryan

**************************************************************************************************************

I am in trying to customize the the standard leave request WF 12300111 to a 2 level approval and therefore i copy this wf out to customize it. I created one of the step to change the Req.status container back to the status "SENT" so that the second approval can approve it.

What i do was i bind the Req.status to a container i created in a task (cus_req_sta) and the task is tie to my customize BOR object. Then i bind this cus_req_sta to my method parameter in the BOR object and i have the follwing code in my bor method.

BEGIN_METHOD ZLEVREQ CHANGING CONTAINER.

DATA:

LEAVESTA TYPE PTREQ_HEADER-STATUS.

V_LEAVESTA TYPE PTREQ_HEADER-STATUS.

SWC_GET_ELEMENT CONTAINER 'cus_req_sta' V_LEAVESTA

V_LEAVESTA = 'SENT'.

SWC_SET_ELEMENT CONTAINER 'cus_req_sta' V_LEAVESTA

END_METHOD.

After i change the value in the method, i bind it back from the method to my task and then from task to the workflow. Everything is fine untill the step to pass the value (sent) from task to workflow. It seems that it does not allow me to pass back the value to Req.status container in the workflow. The Req.status does not updated at all.

The req.status parameter setting is set to import and export when i browse it in the main screen (before entering to the workflow builder). However when i am doing the binding for task back to the workflow (after i drag and drop the req.status and double click on it), it shows the check box for import and export parameter settings is not check.

Anyone have idea? Please help me.....Points will be rewards.....Thanks

Regards,

Bryan

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Bryan,

just to verify the task->workflow container binding: are you trying to bind a simple task container element to the workflow container element Request (class type CL_PT_REQ_WF_ATTRIBS) attributes?

If yes, that won't work since you can't dynamically change an object instances attributes with workflow bindings at runtime (because that would in general make the class instance inconsistent and not depicting the real class instance).

What you need to do is to change the leave request status instead of just faking the change in the workflow. How to accomplish this: replace the coding you have in the background step method to change the leave request status. An example code for changing the request status is given in class CL_PT_REQ_WF_ATTRIBS method APPROVE.

So to reset the status to SENT, just call method cl_pt_req_badi=>initiate_state_transition with im_event = cl_pt_req_const=>c_reqtrans_send and you've changed the document status.

Hope this helps,

-Mikko

Former Member
0 Kudos

Dear Mikko,

Thanks for your reply. Do you know what status that i can change to for my second level approval. I try to change the status to 'sent' and therefore the leave will still be visible to the first approval but instead i just want it to be visible to the second level approval. Is there any status that i can use so that only my second level approval manager can see the leave type and also it will not be process before the second level manager approved it?

Thanks.

Regards,

Bryan

Former Member
0 Kudos

Hi Brian,

yes, the standard leave request approval application picks up all leave requests with status SENT from the approvers subordinate employee list. Resetting the status to SENT after the first approval will thus keep the leave request displayed on the first approvers approval list.

I haven't found a way around this "feature" myself. What we've done instead is to create our own copy of the approval application, pass it the work item ID and make the custom application then retrieve the leave request details for approval (without any annoying second worklists on the leave request approval application).

Of course the most elegant way would be to incorporate a new status for the second approval, adjust the std application to read/write that status as well, but I didn't see that as a feasible option because of major work in the time management business logic.

So in summary, statuses won't help you with the second level approvals and the problem of the leave request approval showing up on the first approvers screen. What I suggest instead is to use another approval tool in the second approval and leave the status as approved from the first approval. The second approval would then be done either as a user decision on the UWL or in a custom web application. The approval result would then just be stored in the workflow as a selected outcome.

Hope this helps,

-Mikko