Posting a journal batch takes about 5% of the total time. This is because deletes are extremely slow (known SQL Server issue).

My solution is to separate the posting of the journals from the deletion after posting of the journals.

To do this, I would update a new flag on the journal batch when the journals have posted.

Then execute a separate routine that deletes all the journals which will result in the Ledger tables not being locked. This will avoid the lockouts that occur when users post a very large journal batch.

Recently had the problem where a user posted 47,000 journal lines and locked the system for over 2 hours.

By separating the posting (using an event), then deleting the journals in a separate process, I reduced the lockout to only about 5 minutes.

🔧 To Reproduce

Steps to reproduce the behavior:

1. Create a large G/L Journal batch (at least 10,000 lines).
2. Click the post.
3. The post will show 100% complete, then take much longer to finish (this is the Deleteall statement when it deletes the posted journal lines.)
4. No error - just very, very slow.

Note: this could be made universal by applying it to all transaction posting. Sometimes sales and purchase orders have a huge number of lines.