cancel
Showing results for 
Search instead for 
Did you mean: 

Question regarding Auth Object P_TRAVL

Lukas_Weigelt
Active Contributor
0 Kudos

Hi guys,

I'm about to murder authority object P_TRAVL, let me elaborate why:

Our designed business process for trips dictates the following:

The Traveler is allowed to read all travel objects there are (with objects I mean Requests, Expense sheets, Plans), he is furthermore allowed to create requests and plans from scratch, to alter requests and expense sheets that are in draft mode and to delete these. Once a request/report is sent for approval, or in addition to it, approved or even further settled etc, he is NOT allowed to do changes or delete anything anymore. So these are the subsequent configurations I made for the authority object P_TRAVL:

...furthermore the Traveler is allowed to create an expense reports on basis of an approved travel request after the trip has been completed. That's what the WDYN FITE_VC_PRESELECTION is predestined for. With some enhancements I got the list only to output these trips:

but, naturally, creating expense reports for it is not possible, because AUTHS W21 is not assigned . If I assign W21, at the other hand, the traveller would be empowered to change approved travel requests and save them back into draft mode, i.e. revoke the business process = armageddon.

What do I do now? This circumstance gives me a paralyzing feeling....

The only thing I can think of at the moment is enhancing all possible parts of the entire FI-TV module where people can click on a button "change" of trips with status 2-1 and statically disable them; afterwards assigning W21 to the Role so this one application, where it's supposed to be possible, works...bah...

Any help is appreciated.

Cheers, Lukas

P.S. goddammit, SAP, goddammit...

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Lukas,

I ran into a similar problem before with the object because users can also change the date of the expenses.

Solution was to wrapper the API and within the wrapper control the date and status of the field.

I interpret that to be what BAPIs are for and the standard WS and WDA are actually just demo apps in my books..  🙂

If the business process "in the wild" wants it differently (and more stable..) the call the stable API and control it via the wrapper application.

Not sure whether this is a widely spread best practice, but works for me.

Cheers,

Julius

ps: Please add the security tag and the SOA (?) tag to this thread instead of cross-posting.

Lukas_Weigelt
Active Contributor
0 Kudos

Hi Julius,

thank you for the quick response. As far as I'm informed, the system-tagging doesn't work yet for mirroring threads into other spaces/places that's why I did this semi legal cross-posting... aside from that, I can't edit my opening post anymore, neither can I close my cross post in the security section..now that I take a look, my updated screenshot doesn't update either... *sigh* anyway..

BTT:

Could you elaborate on using a "wrapper" or "wrapper application" and the "security API"? I asked our Security team about these terms, but they never heard of them or even used them. When I search for terms like "sap security api wrapper" or "sap security api wrapper authority objects" in Google I find tons of UME-related stuffs for JAVA, i.e. Portal applications, which are completely off-topic concerning my problem. When going to SE37 and searching for BAPI*SECURITY* or BAPI*SEC* or the like, I only get a few dozen BAPIs approaching stocks .

Maybe we are talking at cross purposes too. I am on ECC 6.04, i.e. using WDA not WDJ... then again you did explicitely mention BAPIs for WS and WDA, so I guess there is no misunderstanding.

Probably you can point me to one of your books too where some basics are explained concerning wrapper applications, stable API, etc.?

I hope I don't get the RTFM-bat now 😜

Cheers, Lukas

P.S. In the meantime I will also analyze my enhancement-approach to lever out the authority checks at some points, maybe it's not as bad as I think...but usually it is a lot worse than I think.. -__-'

Former Member
0 Kudos

Hi Lukas,

There is definately a big misunderstanding here.. 🙂 I was not implying that there is a Security API for Travel Management but commenting generally on rather using an API to build an own application (wrapper) than to hobble & crook a standard one.

What I meant was that many applications have their own APIs for the functionality required and between the UI and the various API calls you can do validations such as the ones you want without necessarily having to grant authorization or alternately prevent certain functions despite being authorized. This is IMO better than enhancement points and exits within the SAP application to hide buttons -> what happens if the user starts a different WDA or logs on via SAPGui?

Or you could try to report it to SAP as missing granularity in the authorization concept? (most of the checks on P_TRAVL use a DUMMY validation of the AUTHS field anyway...)

Cheers,

Julius

Lukas_Weigelt
Active Contributor
0 Kudos

Hi Julius,

thanks again for the input.

There is definately a big misunderstanding here.. 🙂 I was not implying that there is a Security API for Travel Management but commenting generally on rather using an API to build an own application (wrapper) than to hobble & crook a standard one.

My company generally thinks the opposit way. If we didn't use standard applications, even if "hobbled and crooked" (tsk tsk ) to apply our needs the customizing doesn't provide, we wouldn't be using SAP anymore. I personally also think it's more valuable to alter existing Software products 'organically'  than reinventing the wheel with X times of effort and TCO.

What I meant was that many applications have their own APIs for the functionality required and between the UI and the various API calls you can do validations such as the ones you want without necessarily having to grant authorization or alternately prevent certain functions despite being authorized. This is IMO better than enhancement points and exits within the SAP application to hide buttons -> what happens if the user starts a different WDA or logs on via SAPGui?

I see, that's interesting and indeed to be considered if the possibility exists. I can't argument against whether this is really better than using enhancements since I never used (let alone knew it existed) this UI<-->API concept. Thought, the risks you listed "what happens if a different WDA is accessed" or "what if SAP GUI is used" doesn't really make sense to me; I mean if another WDA is accessed the enhancements don't take effect and they're not supposed to, same with SAP-GUI. Probably you allude to a better centralized control over some application objects with means of UI<-->API, this would certainly be true; but if it's not available..well

Or you could try to report it to SAP as missing granularity in the authorization concept? (most of the checks on P_TRAVL use a DUMMY validation of the AUTHS field anyway...)

That's ..."reassuring" to know... At least those calls I found to be causing my problem didn't use dummies. Even if I pointed out the missing granularity, I dare say SAP won't do anything because they'd have to rebuilt the entire FI-TV module and whatnot if they'd really fix this misconception. The best would of course be, if there were explicit pairs of authf and auths and not some arbitrary pulp. I will most probably point this out to SAP anyway, because some customer-feedback won't hurt.

Cheers, Lukas

Former Member
0 Kudos

Hi Lukas,

If AUTHF controls individual "change" functions, then you can do it.

The authority-check searches for the set of values within each authorization assigned to the user. This may be multiple roles but you can also have up to 99 instances of an object within one role.

So add a new authorization with the W21 in it and in that authorization be more restrictive with the other fields.

Whether the coding construct of the checks supports that is a different story, but it is not actually just one big pulp...  🙂

Cheers,

Julius

Lukas_Weigelt
Active Contributor
0 Kudos

Hi Julius,

If AUTHF controls individual "change" functions, then you can do it.

It doesn't support changing individual pairs of AUTHF and AUTHS, that's the key problem. It's as in "hey do you have authority for AUTHF W21?, yes? Then do whatever the hell you like with any authorities you have from AUTHS and leave me alone".

The authority-check searches for the set of values within each authorization assigned to the user. This may be multiple roles but you can also have up to 99 instances of an object within one role.

So add a new authorization with the W21 in it and in that authorization be more restrictive with the other fields.

THIS is something I didn't know and it does sound like it could work (I always thought roles would be accumulated into one runtime object and THEN be checked). So I'll try making one object with AUTHF W21 and AUTHS 30 and one object without AUTHF W21 and with the rest.

Whether the coding construct of the checks supports that is a different story, but it is not actually just one big pulp...  🙂

The coding apparently is, thank god, always the same:

AUTHORITY-CHECK OBJECT 'P_TRAVL'
     ID 'AUTHP' FIELD authp
     ID 'BUKRS' FIELD p0001-bukrs
     ID 'PERSA' FIELD p0001-werks
     ID 'KOSTL' FIELD check_kostl
     ID 'PERSG' FIELD p0001-persg
     ID 'PERSK' FIELD p0001-persk
     ID 'VDSK1' FIELD p0001-vdsk1
     ID 'PTZUO' FIELD p0017-ptzuo
     ID 'AUTHF' FIELD authf
     ID 'AUTHS' DUMMY.

This code is executed with dummy AUTHS in case of check for AUTHF, if checked for AUTHS, then the dummy-value is replaced by "field auths". Might actually work out, that multi-instance approach. Gonna give it a shot.

Cheers, Lukas

Lukas_Weigelt
Active Contributor
0 Kudos

Yeehaw! It works!

I did as you said, created another P_TRAVL inside the role, gave W21 AUTHF and 30 + 31 AUTHS. It is now not possible to change an approved travel request via FITV_POWL_TRIPS, but it is possible to create an expense report from it via FITE_VC_PRESELECTION. Perfect!

Thanks, JB!

Cheers, Lukas

Former Member
0 Kudos

Sauber!  🙂

Now... if you really want to do this the Rolls-Royce way:

Go to transaction SU24 and maintain P_TRAVL object for each of the two WDA applications with the correct proposal values. Then add the two WDAs via the menu of the role and on the authorizations tab select "Expert Mode" -> "Read new and merge old data". The P_TRAVL will then be automatically inserted into the role(s) with the correct values.

Advantages are mainly, that you only need to research / troubleshoot / trace it once, and anyone in the system using the same applications for roles will automatically have the same behaviour (controlled by the authorizations) and via the where-used-list (icon of the Alps with the sun coming up) you will know (and anyone else in future as well...) where the application object is used and why it is needed by that role. It will not merge them into one instance if they are not uniquely mergable values.

Cheers,

Julius

Answers (1)

Answers (1)

Former Member
0 Kudos

This is how the tables turn - I have the same problem now and cannot get it to work...  so I searched and found this... LOL... 😉

We have activated structural authorizations and P_ORGINCON. We are using ACTEXP_APPR_LITE via NWBC to approve working times and travel expenses.

For times the org structure works fine and the chief can see and approve times of their direct employees. All ok.

But for travel expenses they can see and approve everyone if they are a chief and have the MMS role. The auth trace is showing that KOSTL is checked, but we dont want to control via that as the cost center hierarchy does not exactly match the org structure and the org structure seems not to be pulled for the chief to show only the trips of their direct reports.

AUTHF seems to be the (rather complicated) solution.. but I cannot get it to work. Particularly that the org structure is used to offer only direct reports for approving the trips.

How did you get my mentioned solution to work? Perhaps I am just getting old... 😉

Cheers,

Julius

Lukas_Weigelt
Active Contributor
0 Kudos

;-D

Since you did the needful back in 2012 I can now revert to do the same! Good Karma shall come to you (hopefully). In general, AUTHF and AUTHS should both be checked by the standard coding, is that the case for you as well ? (because you only mentioned AUTHF). Anyway, here's how I split up the P_TRAVL Objects for my original question after you taught me that you can have multiple objects of the same type:

If that doesn't help you, can you elaborate what exactly your requirement concerning the trip statuses is (or rather whether it concern the trips statuses at all)?

Cheers, Lukas

Former Member
0 Kudos

Thanks Lukas!  🙂

The ESS role is working fine, where the personnel number check = O and AUTHs restrict changes depending on the status.

My problem is in the MMS role and the travel approval, where I must also authorize for other users(employees) that the manager can approve the travel expenses. Here it is asking for cost center, but we want the list for approvals to follow the organizational structure and not the cost center assigment. It does not follow the org structure to find the direct employees and when I grant KOSTL then they can approve too much - that is my problem.

I subsequently found that there is a personalization key which influences it (DIA_CO_CCA_TR) which offers the option to configure the approval via org structure or user lists or cost centers. That looks promising but I have not got it working yet.

Do you use it or other personalizations for control here?

Cheers,

Julius

Lukas_Weigelt
Active Contributor
0 Kudos

Now I'm starting to understand. You're using FITV_POWL_APPROVER and the evil powl framework doesn't allow for a detailed enough differentiation.

Back when I designed our FI-TV processes (2012 --> EHP4) I abandoned FITV_POWL_APPROVER, because the Personalization options (FPB_MAINTAIN_PERS_S) for DIA_CO_CCA_TR for selections via H(Org Structure) and S(Cost Center) were FUBAR and the powl framework was horribly bugged in general. Instead I designed a workflow and use the Universal Worklist for Approval End User UI which works 100% realiably (take that, POWL).

In Theory, what you'll want to use is something like this (maybe it works by now in EHP6/2015..):

I'm unsure whether such a dynamic selection can be maintained 1-1 in P_TRAVL (I assume that isn't possible), i.e. the manager will authority-wise always be able to "do more" than he actually is presented with by the powl personalization.

In Praxis, you'll want to throw FITV_POWL_APPROVER far away and use a workflow instead, because then you can just program it yourself within the AC-Rule of the decision task.

Cheers, Lukas

Former Member
0 Kudos

Yes, exactly that is what I am trying to do.

It is not comforting that you threw it away for the same reason that I am asking here... but I will keep my hopes up and continue further for a while still. Customer says she wants it to work properly and does not care how. It must just work... 🙂

Cheers,

Julius

Lukas_Weigelt
Active Contributor
0 Kudos
Customer says she wants it to work properly and does not care how


If the "does not care how" is to be taken seriously, then, given the Personalization dialogue still doesn't work for H(Org Structure), you can just enhance the WDYN Comp that selects the Employees basis for the Approval Dialogue and code the selection yourself. That's what I did before having serious doubt realizing our company structure was so complex you'd need to write an AI to automatically derive approvers from it. And it did work out (to a certain degree). Maybe that's worth a thought for you too.


Cheers, Lukas

Message was edited by: Lukas Weigelt

Former Member
0 Kudos

The thing is that in the selection screen of ACTEXP_APPR_LITE there is a dialog to select the org.structure and then it is restricted. My hope was that the personalization key would set that and the docs suggest that it does do exactly that, except that it does not work to set that selection.

So plan B it was: we created a screen variant which sets the selection of the org-structure flag and created a parameter transaction which passes the variant as a parameter to set the screen.

The personalization would however still be a more elegant solution. Even better would be if travel expense approvals could respect the org.structure when activated in OOAC, in the same way that time approvals does.

Why the two are different is also a bit puzzling. Surely there must be many customers out there who would want exactly that? Or they all use UWL and not POWL wyda's (which was recommended to the customer, expecting that authorizations will be easy).

Cheers,

Julius

Lukas_Weigelt
Active Contributor
0 Kudos

I completely overread that you use the old ACTEXP_APPR_LITE Transaction and not WDA. This makes things even more complicated (IMHO).

Your Plan B does already sound pretty elegant to be honest (considering the Fact that it's old Dynpro technology), the next alternative would be diving through the available BADIs.

Why the two are different is also a bit puzzling. Surely there must be many customers out there who would want exactly that? Or they all use UWL and not POWL wyda's (which was recommended to the customer, expecting that authorizations will be easy).

The "official recommendation" is using the WDA scenarios (including POWL), because WDJ and most of the transactions are either obsolete or "only being maintained" which means nobody maintains them really ( might come around the corner and scold me for uttering this). Most people I know use either the Traveler work center FITV_POWL_APPROVER with the POWL Personalization Framework or a Business Workflow with any UI for Approval (POWL, UWL, Unified Inbox, doesn't matter) --> You can 'push' Workitems into a POWL as well but certain WF-Parameters tables like SWFVISU are being ignored which makes that quite uncomfortable.

IMHO go for your plan B or alternatively raise a message, but you might score a #12 😐

The one thing I don't understand, though, is, why does your customer implement a new functionality and uses ancient technology (Dynpro) for it? Launching it via NWBC doesn't make it any better IMHO. That's just the designer in me speaking, though.

Cheers, Lukas

Former Member
0 Kudos

Someone recommended it to their management and it sounded nice...

Then I was asked to do the authorizations shortly before go-live...

😞

Cheers,

Julius

Former Member
0 Kudos

In the end it worked with the custom transaction to start the ACTEXP_APPR_LITE with a screen variant. Trick was to create it with a user with ALL in OOSB, set all checkboxes for all org units -> when the application use logs on the org structure is pulled and only sets the flags for the units they are assigned to (despite showing that 400 org units are chosen). If they only have 1, they only get the flag set for 1 as the others are not there. Then we protected the variant.

The auths you have for the ESS role with P_TRAVL worked exactly as it worked for you (personnel check = O).

The MMS role still needed some tweaks because personnel check = E and needed an equally complicated construct (so that managers also cannot change the status of an approved trip and pay it twice).

But I wonder to myself why an object actually needs 10 fields and the fields themselves have a control logic which is a concatenation of 3 values into one field, each of which in combination with the other values and the other fields in the same instance of the authorization control what the user can do. Encryption and decryption is easier than that to program and implement.

Going through the code of the check methods, I kept thinking that a simple set of popular customizing switches to banish some options regardless of auths and respect for org.structure instead of making it a selection dialog for the user would have been much easier than offering a BADI, or personalization which did not work.

I guess SAP abandoned this in favour of relatively authorization neutral UWL and workflow, but I suspect there are many customers out there who suspected that they can configure it in a few hours with a wizard and it will work out of the box.

Not...

Cheers and thanks Lukas for your help and advise. I took 200 pages of notes. Do you want them?  🙂

Julius

Lukas_Weigelt
Active Contributor
0 Kudos

Glad things worked out for you eventually 🙂

The MMS role still needed some tweaks because personnel check = E and needed an equally complicated construct (so that managers also cannot change the status of an approved trip and pay it twice).


Yes, we had a similar problem concerning P_TRAVL. We have ESS Users who are allowed to maintain themselves but not others (regular mortals) check=O, MSS users vice versa check=E and Power Users who also use the WDA UI and have a mix of both ESS/MSS + special structural authorization. This was quite messy to implement in a consistent manner.


I took 200 pages of notes. Do you want them?  🙂


Why, of course! Alternatively you can release another book of our all-time favourite series "How To XYZ in 5 easy steps" concerning FI-TV Authorizations ;-))


Cheers, Lukas