cancel
Showing results for 
Search instead for 
Did you mean: 

Expense Report User lock error- E-RP001 Key (Pernr) is locked by user

Former Member
0 Kudos

SAP Travel Management-

When Approvers return a trip back to employees for corrections, the trip does not go on "hold" automatically in some cases. The user is not

able to modify his exp report for corrections. This same lock error occurs when trip is going for approval or settlement too.

The workflow shows an error-

"E-RP001 Key (Pernr) is locked by user ..".

The Workflow ID is- WS90000005.

In almost all the cases, the trip is locked by the user who created the trip himself. Need to identify why this trip gets locked, is it because the user is

accessing any specific screens/transactions when workflow is being approved/rejected?

How do we avoid such errors?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

depends on what your WF is doing, and how.

Generally, you will have lock entry whenever trip has been opened in change mode in PR05 or WD4A. If e.g. WD4A window is closed beyond navigation, lock entry may remain for a while.

so you should have some exception handling in your workflow to reprocess WF in that case, temporary parking WF until RSWWERRE picks it up 20 min later.

Pls also check if it is REALLY a lock entry: There is a very nice joke from Walldorf in the templates, where step description of a task has been named "PersNr is locked...." or similar. This is not a real lock entry but a wrong description text.

To find out real error, check WF log/ technical details. Maybe it is a completely different issue in real life.

cheers, Michael

Former Member
0 Kudos

Hi Michael,

Thanks for your reply. My knowledge of Workflows is minimal so I may ask very basic questions.

The WF log/tech details do say that this is a lock error. The container shows the error "E RP001- Key () locked by User ()"

Its not possible for users to open their trip in change mode once they send it for approval. Will opening in display mode cause this too?

Currently, a temporary error is shown until the WI is restarted after 20 mins (thrice) by RSWWERRE. But generally, the lock still lasts after 3 tries and no further processing happens.

In most cases, the user/approver is unaware that his trip has errored out and hence they are susceptible to late charges via the card provider.

Currently, through SWI2_DIAG, we monitor workflow lock errors and restart the step manually.

Is there a way to send a notification to the user or approver informing them of the error?

Regards,

Karan

Former Member
0 Kudos

Hi,

again: this text is only a description text of the task. It will always be displayed, no matter if processed successfully or with errors, or without indicating the type of error

the "real" error will most probably be something completely different.

Pls check

SWI2_DIAG: what does it say? maybe provide screenshot. If it is with errors again and again, one of the steps cannot be finished, for whatever reason. Maybe some method fails, maybe some data has not the right format to be written, maybe an email address cannot be determined, ....

SWI2_ADM1: Any entry here for that item? Most probably not.

SWIA: go to WF log (the paper roll icon), then navigate to technical view (the icon with the three columns, one of those blue). Expand your WF steps until you find the last one which has errors. Click on tab technical details to see status red or green, and maybe get a real error ID. And pls also check the container tab if all data are there as expected. Minimum is primary keys WI ID, Trip Nr; Pers Nr and the elements used in data binding of task assigned to step

To help you further, I need:

- Screenshot of SWI2_DIAG indicating error

- Screenshot of WF log, graphical view: last two or three steps which have been performed

- Screenshot of WF log, technical details: last step performed and its status

rgds, Michael

Former Member
0 Kudos

Hi Michael,

Below are the SWI2_DIAG screenshots-

The Workflow log with technical details-

The container has the Pernr, Trip ID WI ID, etc basic data when drilled down-

Graphical Workflow details-

Really appreciate your help on this issue. Pls let me know if I should provide any additional information.

Former Member
0 Kudos

you have to "loop" until user is unlocked. So if locked loop in 5 minutes....

(actually have you tried to test this workflow step by step and leaving the transaction before go for approval?)

Former Member
0 Kudos

Hi,

So this is not the text I mentioned earlier but a real lock entry.

It is unusual that user is locking for such a long time.

Can you pls check in SM12  at the end of a day if there are many "old" lock entries for PTRV_HEAD > 1h, which indicate error at some stage during enqueue/ dequeue handling.

Actions like closing WD4A browser window may end up in a remaining lock entry if session handler is not working properly. Own methods in WF, especially changing trip or status, may cause lock entries as well.

So how is status change performed? Standard method "Approve", or individual method? Can you check here if some enqueue of lock entries is applied? Do you have other previous steps which may cause lock entry, maybe with a submethod during approval or similar?


Remote analysis gets hard for this now - you'd need an experienced WF guy analyzing on your system.

Try to reproduce with a new trip, sending for approval - and have SM12 refreshed after each step to see when see lock entry is effectively set. 1) remaining lock after entry or 2) new lock during some WF processing.

If you have authorization, you can execute the workitem on your own, taking over from workflow log.

regards, Michael

Former Member
0 Kudos

Hi Michael,

Thank you for your inputs.

As suggested, I checked SM12 after every step of execution. Found that this user lock error pops up only when PTRV_HEAD is locked by the user. This table gets locked when the user is either creating a new trip or editing an old "on-hold" trip.

The locks on this table were released as soon as I quit the txn.

Also noticed that at any given time (during business hrs) around 5-6 ">1 Hour" locks were present on this table. But having tested that no locks are lingering after SAP txns have been exited, it suggests that WD4A may be the problem. Or may be users actually have screens open the whole time (have asked Basis to check which txns are actually being accessed).

Will post as soon as I have any further updates. Once again, thanks for your help.


Regards,

Karan

Answers (0)