Ron,

First you should report this case through our support channels. My gut feeling here is that you shouldn’t get this problem.

For shop order components, where you have enabled the toggle Availability Check in Inventory Part, system runs above background job to remove and re-generate Planning Alerts for your components that have an availability problem according to the availability check (same logic that is used when you enter customer order lines). This job could be kicked in quite frequently - and it is per shop order component line.

These planning alerts are also removed when you issue a component line fully or close the the shop order component line (shop order close)

I guess what can happen here is that a user modifies the shop order and then issue the shop order component line. What then could happen is:

1. User inserts / modifies qty or date of a shop order component.
2. Background jobs are created. From an Oracle point of view, these jobs are managed in another user transaction.
3. These jobs queues up…. and are not processed immediately...
4. The user (or another user) continues to process his/her shop order and issue the component fully. => Planning Alerts get removed. But since issue/bacflushing online transaction can consume some time because of Inventory Transaction History records gets generated with all the costing & posting rules on top of that, this transaction perhaps takes 2-3 seconds. 
5. At the same time the jobs at #3 above executes and try to lock the planning alerts prior removing them. => Here we get your reported problem.

Anyway, I think we can mitigate this problem in Core, so please report a support case.

Also we could try to make the error message more user friendly.

Nice if you also can provide a screen shot like below when you report the case

...Coz then we also know if the availability check consumes a little bit of extra time.

I hope above was a little bit of help and not too confusing.

-Mats

​@majose many thanks.