Reversing the process of Assigning POWL Travel Assistants
This blog shows a compact custom approach of reverting the process of the assignment between a traveler and a travel assistant via POWL Personalization. What follows has been done on a system on NW 7.03 (731) ECC 6.06. Since I got an overall good feedback on my latest (and first 🙂 ) document over here Adding fields in Travel WDA Applications, I decided to stash away some more knowledge on the forums 😉 , so here we go.
You don’t really need any in-depth technical knowledge to understand the following, though basic understanding of how POWL works won’t hurt.
1. What SAP provides
The basic idea of POWL is pretty much “Person A assigns an amount of people to himself on certain conditions for particular business processes”. POWL-experts might want to burn me alive now for summing it up so generically in one sentence, but that’s just how it is in my opinion. In case of FI-TV, for example, we have the role of a Travel Assistant who can assign an amount of Travelers to himself to allow for the creation of Travel Requests/ Plans and Expense Claims on behalf of those Travelers. Alternatively to this way of assignment, it can be done centrally in the backend using the transactions FPB_MAINTAIN_PERS_S and FPB_MAINTAIN_PERS_M ( refer to Sally Redmond‘s KBA #1622954 ).
2. What some people (I myself amongst them) expected
Instead of the Travel Assistant deciding himself who he is an assistant for, in my company there was the requirement for the travelers being able to freely decide who’d be supposed to be a travel assistant for them (central maintenance was no option due to TCO). The idea of SAP’s designed assignment-process inevitably resulted in the fear the assistant would be given too much power and might abuse it (given the fact that structural authorization is not supported in FI-TV; even if it was, it would still cripple the flexibility from a different point of view where some relations might stretch across the regulations of structural authorization).
Bottom line our business process was turned upside-down.
3. How to rebuild what SAP provides into what we needed
Basically, there are three sources in the system that are relevant for this approach, these are the Function Modules FPB_PERS_READ_FOR_DIALOG, FPB_PERS_POST_FOR_DIALOG and the transparent table FPB_PERSPARM (which holds the very personalization data). What I did, was create a custom WebDynpro which provides the following logic/process steps:
- When the Application is started, FPB_PERSPARM is read with a mere database select for LOW = the PERNR of the User that is logged on for the Travel Approval Dialogue (used for both, Approvers and Assistants in FI-TV). This selection itself already is kind of ‘backwards’ concerning the actual SAP process. The output is presented in a table (record sets for the single Assistants).
- The user is given the possibility to delete a record set of this presented table, after which a hard delete statement on FPB_PERSPARM is issued. I conciously don’t use FPB_PERS_POST_FOR_DIALOG here, since it tends to bug out if there’s only one assistant left and you try to delete it. After the deletion is done, I run a submit of POWL_WLOAD for the Travel Assistant whose assignment has been deleted for, else the old query is still in the POWL-Cache.
- The enduser is also given the possibility to do a search for employees in the system who are authorized to be a Travel Assistant (indicator is a particular R/3-Role) and then assign the selected person to be oneself’s Travel Assistant. This ‘assignment’ is then done via FM FPB_PERS_POST_FOR_DIALOG. Just like within the deletion process, POWL_WLOAD is submitted for the chosen Assistant to refresh the POWL queries.
Of course I also coded a lot of plausibility checks as well as certain gimmicks, auth checks etc. etc. But the stripped down process is really simple as you can see. The whole thing only took me a few days of work. The simplicity of this particular development, though, also brings some inflexibilities; the process only works as long as the personalization sets are maintained with single LOW-Values (at least the way I coded it, of course you could make it more complex and flexible), i.e. no intervalls etc, but it’s sufficient that way for us. Here are some screenshots of how it looks like:
Links with stuff around the topics involved in the blog:
SAP Community Network Wiki – Web Dynpro ABAP – POWL
Demystifying POWL and Feeder Class in Travel Management
Personalization of Employee Lists – ESS and Mobile Use in Travel Management – SAP Library
Travel Assistant – Financial Accounting (FI) – SAP Library
That’s all folks. I hope it’s interesting for you or at least amusing in case you think this entire fabric is completely ridiculous 😛
P.S. I am aware of my horrible spelling in the pictures, but I’m too lazy to replace them 😏