Question regarding Auth Object P_TRAVL
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.
P.S. goddammit, SAP, goddammit...
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... :-)