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 :smile: ) document over here Adding fields in Travel WDA Applications, I decided to stash away some more knowledge on the forums :wink: , 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:
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 :razz:
Cheers, Lukas
P.S. I am aware of my horrible spelling in the pictures, but I'm too lazy to replace them
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 |