Able to change APPROVED travel request

[Former Member]

All,

We are able to change travel requests that have been approved.   I found an older OSS note 1242420 - POWL Change button still available when trip is nonchangable which makes me think we should not be able to change the travel request.   Is there configuration we have to do or is it customization?

As you can see from the print screen the request has been approved but the CHANGE button is enabled.   We want the CHANGE button to be disabled.   This is working as expected for Expense Reports and I have not been able to find any custom code.

Thanks

Sandra

.

[Former Member · Accepted solution]

Richard,

How do you tell it to allow the user to change the travel request ONLY if the travel reqest has not been approved?

Sandra

[richard_wingerd2 · Accepted solution]

Sandra,

We doing by assigning a possible action to each trip possible trip status.  Here is SAP's description

You can define the characteristics for the operation and the status of a trip during single entry in the AUTHF field.

The field is three characters long. The first character is for the relevant operation, the second for the status of the travel request and the third for the accounting status of the relevant trip.

The first character can be any of the following:

• R ... read trip data

• W ... write trip data (create, change, copy)

• D ... delete trip data

• X ... account trip data

• S ... Evaluate statistics database

• * ... all operations.

  The second character (request status) can be: 

• _ ... new trip (characteristic blank)

• 1 ... request

• 2 ... request approved

• 3 ... trip

• 4 ... trip approved

• 5 ... request on hold
  6 ... trip on hold
  * ... all statuses

  The third character (accounting status) can be: 

• _ ... new trip (characteristic blank)

• 0 ... open

• 1 ... to be accounted

• 2 ... accounted

• 3 ... cancelled

• 4 ... posted (FI or Payroll Accounting or DME)

• * ... all statuses.

Examples of characteristics for AUTHF:
R41 Read an approved trip which is to be accounted.
W   Create a new trip.
W22 Change an approved request which has been accounted
D1* Delete request
X41 Account an approved trip which is to be accounted.
S*  Display statistics for all trips

There is quite a bit of flexibility here but it can be tedious to setup and test due to numerous possible combinations.

Rich

[Former Member]

Just to update - we did have the security profiles created as suggested and the tester said it did not work as they expected.   I have not taken the time to look into this further.  Most likely we are doing something slightly different than what is expected and that could be throwing off the solution.

Thanks for your input.

Sandra

[Former Member]

Lukas,

Thanks - you just made my day! 

Sandra

[Former Member]

Lukas,

Thank you for the link to your post.   I know it must look like I did not do my due dilegence and search for a solution prior to making a post but I did.  I just didn't ask the right questions or use the correct key words and I have to admit I was in a hurry.  You are also correct, I know very little about what I am asking for so didn't know to use P_TRAVL in search until Richard mentioned it. 

Richard, Lukas - thank you both.   I have passed on all of this information to the consultant and he is working with our security team to set the authorization up the way you recommend.   I was waiting for the results before I updated the message which is why you haven't heard from me.

Sandra

[Lukas_Weigelt]

Hi Sandra,

just to set things right: Nowadays I've stopped to answer posts that look like the OP hasn't done any research, isn't really trying or isn't providing enough information, IMHO that doesn't go for you. Also, my intention behind linking to my thread with Julius wasn't a broad hint given but really just a well-meant addition to Richard's post, because I felt in my thread the whole issue was elucidated more detailed than here.

Furthermore, as you can see in the thread with Julius, me being an Authorizations-Noob, I didn't know what the hell I was talking about, but I asked my way through and got the information I needed in the end. There's nothing wrong with that as long as the counterpart doesn't lose his temper and hits you with the RTFM-bat

The one thing that makes me a tiny bit angry is, seeing that people who call themselves consultants spread poor/bad/wrong information among their clients instead of saying "I don't know" and probably get overpaid in return. At these times I thank SAP for providing SCN as a platform where you can, for example, get a second opinion.

So, bottomline: Don't worry, we're good. Keep it up!

Cheers, Lukas

[Former Member]

Rich,

OK the light bulb of understanding has gone off.  I do have a few more questions.  Comments from the consultant who is working on this for us:  "AUTHF value of W21 for P_TRAVL authorization object ensures that an expense report can be created with reference to the already existing travel request (desired). However, this same value also allows approved travel request to be changed! (not desired). Hence this cannot be controlled by authorization." 

My question is there is an authorization F_TRAVL for Travel Planning we currently have M, R, W

do you think if we were more specific in that authorization that would stop them from changing an approved travel request but still create an expense report?

Thanks

Sandra

[richard_wingerd2]

Sandra,

What you can do is maintain multipe P_TRAVL further restrict activity.  In your situation, I would put W21 in the AUTHF field and then in the AUTHS field put 30, 31.  With this combination, only an expense report can only be saved as "trip complete/Open or trip complete/to be settled" while the travel request status will not change.

Adding multiple P_TRAVLs does add complexity to the testing as it can become tedious as every change requires a retest of all possible scenarios.

Rich

[Lukas_Weigelt]

Hi Sandra,

Richard already provided the correct answer in his latest post, I just wanted to highlight my thread over here that covered the exact same issue and my discussion with Julius; it might help you to understand the problem more in-depth:

Oh and by the way, the following portion of your "consultant" is correct....

"AUTHF value of W21 for P_TRAVL authorization object ensures that an expense report can be created with reference to the already existing travel request (desired).

...but the second bit is bad information, see Richard's correct explanation, i.e. as long as you don't have any instances of P_TRAVL where AUTHF = W21 and AUTHS = 21, an approved travel request cannot be changed and saved again as approved travel request.

However, this same value also allows approved travel request to be changed! (not desired). Hence this cannot be controlled by authorization." 

Cheers, Lukas

[richard_wingerd2]

Sandra,

We utilize security settings in P_TRAVL/authf to control what can be done with a trip. It is likely you have these settings in place for the expense side and will need to update/add additional entries for the travel request.

Hope this helps.