Routing of workflow items different in UWL and FITV_POWL_APP

[Former Member]

Hi,

We have activated workflow WS90000011. I have also activated

application FITV_POWL_APPROVER. The intention of the latter is for

user to approver the expense claims via the FITV_POWL_APPROVER instead

of via UWL. The key reasons are that user can enter the rejection reason and also see all the details in 1 screen.

In our workflow WA90000011, we route the workflow item to reviewer and approver by

referencing a customized table rather than via the HR org structure. The routing as shown in UWL is correct. However, when I go

to FITV_POWL_APPROVER screen, I do not see the work item there for approver.

Illustration

HR Org structure: A -> B -> C

Customized table: A -> C

In UWL, after A submits the expense claim form, C receives the notification in UWL. It is correct. However, when I go to the application FITV_POWL_APPROVER, I see the work item under B and not C.

Why is this so? We did not make any change for FITV_POWL_APPROVER. It is as per standard. Also, after B clicks on 'Approve'

in FITV_POWL_APPROVER, the expense claim is approved. It does not route to C?

Has anyone attempted to use FITV_POWL_APPROVER before?

Thanks.

[Former Member · Accepted solution]

Hello

As far as I know FITV_POWL_APPROVER is not linked at all to any workflow.

The approver is determined by personalisation via appl id CO-CCA-TR. The function module PTRM_WEB_PERNRS_GET is used to determine all the pernrs related to an approver.

POWL and UWL are very different component :

- UWL is based on workflow (like a SBWP with filter).

- POWL is based on coding (via ABAP class) and could be completly used without any workflow.

[Former Member · Accepted solution]

Hi,

Thanks for your reply.  I noticed that FITV_POWL_APPROVER only has 1 level of approval?

Is it possible for A (submit expense) -> B (for review) -> C (for approver)?

[Former Member · Accepted solution]

Hi

yes unfortunatly in standard FITV_POWL_APPROVER has only 1 level of approval.

It is possible to do a multi level approval with specific coding (It is a common requirement and I did it for almost every customer...).

[Former Member · Accepted solution]

Hi,

Thanks for your reply.  Able to provide some guidelines how and where can we do this specific coding?

[Former Member · Accepted solution]

of course, here is the general idea :

- Customizing of POWL is done using POWL_COCKPIT transaction

- Behind every POWL query (in your case FITV-POWL-TRIPSFORAPPROVAL) there is a feeder class. This is an ABAP OO class with methods defining actions and list of objects to retrieve. You will need to enhance this class (or copy it and change it in customizing). The standard class is CL_FITV_POWL_TRIPS_TOBEAPPROVE.

- Now you will need to override the most important method which is GET_OBJECTS, this is the method retrieving the list of trips to approve.

-In your case you will need a custom Z table to record the "validation path", then read this table to find who is the next approver. Until it is the last one just update a status in your custom table, when it is the last one use the standard approval method to set the approved status. (if it is a rejection you can alway use the standard).

Hope this helps

[Former Member · Accepted solution]

Thanks!  I have one question.  Do you know where is the rejection reason text stored?  Which SAP table?

[Former Member · Accepted solution]

If I remember well it is not stored, it is only sent by email.

We are a bit far from the original topic, for the quality of the forum, you should open a new thread for different questions

[Former Member · Accepted solution]

Hi,

Earlier you mentioned that under FITV_POWL_APPROVER, you managed to customized to allow more than 1 level of approver.  Would you be able to share some details on how to go about doing this?

[Former Member · Accepted solution]

Yes it can be done with specific coding. As I said in my previous message :

- Customizing of POWL is done using POWL_COCKPIT transaction

- Behind every POWL query (in your case FITV-POWL-TRIPSFORAPPROVAL) there is a feeder class. This is an ABAP OO class with methods defining actions and list of objects to retrieve. You will need to enhance this class (or copy it and change it in customizing). The standard class is CL_FITV_POWL_TRIPS_TOBEAPPROVE.

- Now you will need to override the most important method which is GET_OBJECTS, this is the method retrieving the list of trips to approve.

-In your case you will need a custom Z table to record the "validation path", then read this table to find who is the next approver. Until it is the last one just update a status in your custom table, when it is the last one use the standard approval method to set the approved status. (if it is a rejection you can alway use the standard).

Which part isnt clear ?

[Former Member · Accepted solution]

Hi,

I wanted clarifications on the last point.  Is there any further configuration setup to enable 2 level approver or it is purely controlled via the program to check against our customized table?

In your previous implementation, do you have a customized table to track who is the next approver per expense claim number?

Thanks.

[Former Member · Accepted solution]

It is purely controlled by the program (ABAP OO class).

Yes I always did a customized table because it is very usefull for :

- Reporting purpose (who approved, time between full approval of all approvers... and so on).

- Keeping a link with workflow if I need one (workitem id in the table).

[Former Member · Accepted solution]

Thanks for your prompt and detailed response