Pernr could not be locked' error while using FM BAPI_EMPLOYEE_ENQUEUE

[Kirubakar]

Hey Guys,

I understand this is a very common issue and has been asked here in the forums extensively, but hear me out here! Trust me, I have checked so many posts here in the community and tried a variety of different things. But no luck.

Business Scenario: I am trying to modify Infotype 41 nd add a certain date type through a BADI when P2P replication happens from SuccessFactors to Employee Central Payroll.

Sequence of Calls:

1. BAPI_EMPLOYEE_ENQUEUE

2. HR_INFOTYPE_OPERATION

3. BAPI_EMPLOYEE_DEQUEUE

Standard stuff right?!!!

Guess not!

I get an error during 'BAPI_EMPLOYEE_ENQUEUE

Error:

Solutions Tried:

- I am following the best practice and only locking the employee once per all the info type updates

1. Checked IT003 if the employee is locked - Not locked

2. Tried Running 'BAPI_EMPLOYEE_DEQUEUE' in SM37 and then tried running the BADI again. - No Luck

3. Checked SM04 - I cant see any User based lock on that employee

4. Check SM12 - Nothing!

5. Ran FM 'ENQUEUE_READ' to check for any locks on the PERNR - nope NADA

6. Even tried 'IF_HR_ENQUEUE_OBJECT' - Yup you guessed it.... NOTHING1

I have tried everything. What could be the issue?

Thanks

Kriba

[ThangaPrakash]

@Kriba Ezhilmani I could see you have tried most of the possible options, nothing has worked out.

As I guess before we access any HR data, authorization comes into picture, it could be possible user id inwhich you are running the program doesn't authorize to read any HR data which could have caused failure in locking.

Check with Security team and try taking Authorization trace to check if any authorization is failed when you run ENQUEUE.

[Kirubakar]

Thanks for the info man. But I don't think that's the issue because we are using the same user to create/delete other infotypes like 0014 (recurring) and modify 0008 and it works out fine. With 0041 infotype its not working.

[Kirubakar]

Resolved: The issue was that a double locking was being attempted. The system locks a PERNR for the P2P replication to happen. And in the BADI I was attempting to lock the employee again using 'BAPI_EMPLOYEE_ENQUEUE' before updating the infotype, which is the best practice. This was causing the issue. Once I removed the locking mechanism within the BADI, it worked perfectly.