Skip to Content

Problem with employee dequeue


In a customer report there is a sequence of function modules callings in the loop:





We use the report to register data in infotypes 0014, 0015, 0267 etc from customer table, which is loaded from file in previous step. When registering different wage types on different days for one personnel number, we observe, that in some loop steps the fm BAPI_EMPLOYEE_ENQUEUE returns that employee number is still locked, in spite fm BAPI_EMPLOYEE_DEQUEUE was executed in previous step. In some cases it could happen that another user has locked the employee in meantime. But the problem is also on test or quality system, where it is impossible that another user locks the employee. The fm BAPI_EMPLOYEE_DEQUEUE does not return any return code or exception, because it is not filled at all, so I cannot be sure, that the personnel number is really unlocked.

The problem does not exist while debugging, that is with time delay. I have prepared test log in SM12 and I have noticed that in the next step of loop employee is locked when there is no locking code "DeqAll" in previous step (compare the attached file SM12.png and data for IT0015 DATA_IT0015.png - red lines are those with locked pernr error). I assume, that this action is initialized by fm BAPI_EMPLOYEE_DEQUEUE, but, as I mentioned above, there is no possibility to check return code, because it is not filled.

The report worked fine for 2 years, but 3-4 months ago it begun to fail constantly. I know how to improve the report to avoid error of locked employee. I want to find out what is the reason the lock remains after BAPI_EMPLOYEE_DEQUEUE. Any suggestion what possibly may I check?

Best regards,


DATA_IT0015.png (35.5 kB)
SM12.png (543.2 kB)
Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • Best Answer
    Posted on Sep 12, 2016 at 12:47 PM


    Hint: HR_MAINTAIN_MASTERDATA and similar called FM will execute a COMMIT WORK without the WAIT option, so sometimes the update task will not be completed before the next Lock Request, only the current LUW lock will be released, no the update task. So consider using the NOCOMMIT parameter and then use a COMMIT WORK AND WAIT statement.



    Add a comment
    10|10000 characters needed characters exceeded

    • Raymond,

      The synchronous COMMIT WORK AND WAIT does work a lot better than the standard aysnchronous COMMIT statement, but I found that eventually this also stops working when server and database loads are just right. I have just posted a blog ( Waiting for lock objects to release - using lock modes U and V ) about using the ENQUEUE function module to check and wait for locks to finish their DEQUEUE operation. So far, this method has not let me down.

      I am not familiar with these HR functions enough to know if this can replace BAPI_EMPLOYEE_DEQUEUE or not. However adding another ENQUEUE_EPPRELE at the end - after the COMMIT WORK AND WAIT - with Mode 'U' or 'V' and a _WAIT = 'X' should help. It will check for lock collisions and wait when needed.

      Hope this is useful.


  • Posted on Sep 14, 2016 at 06:00 PM


    Your hint is the solution. Thanks for Your help.



    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.