“You can’t complete this process while transactions are being edited,” is a common error that I see at least 3-4 times a month from various clients. This error can happen on almost any screen or even when you try to exit GP right after you opened the program. Often times if you wait a moment and try the action again the warning will disappear. It is seen when an end user opens Microsoft Dynamics GP and then try to immediately close the program. I have several steps I take to troubleshoot.
First I wait a few moments and try again. If the error persists then I would first have everyone log out of GP and then go into task manager and force a log off for the end user.

Then I would apply a script to clear the temp tables after all users are out of GP.
First I would check to see if these 5 tables are clear after everyone is logged out.
SELECT * FROM DYNAMICS..ACTIVITY
SELECT * FROM DYNAMICS..SY00800
SELECT * FROM DYNAMICS..SY00801
SELECT * FROM TEMPDB..DEX_LOCK
SELECT * FROM TEMPDB..DEX_SESSION

If there is any data in this table then run the delete version of this script to clear the 5 tables.
DELETE DYNAMICS..ACTIVITY
DELETE DYNAMICS..SY00800
DELETE DYNAMICS..SY00801
DELETE TEMPDB..DEX_LOCK
DELETE TEMPDB..DEX_SESSION

After these scripts are completed, I would then run the process again to see if it still persists.

If the issue still persists then there could be a duplicate transaction that is hanging around in the Microsoft Dynamics GP tables. Microsoft Dynamics GP is purposely designed to have separate tables for WORK, OPEN and HISTORY transactions and because of this division, it is possible to have transactions stuck between tables or even have duplications. More specifically, when the triggers in SQL were activated they did not clear the previous table in the correct order. Let us say that you have a Purchase order batch that was running before you got the error. The tables this batch would use are the PM1000, PM2000, and PM30300. It is possible for one or more entries to be in the PM100 and PM2000 or even the PM2000 and PM30300. The best way to detect this is to run the duplicate transactions script on this link.  Dave Musgrave created this script and you would run it on the modules to see where the duplications lie.
After I identify which module, I will do a lookup on all the tables within his script to see which are the culprits. After IDing where the problem lies, I will then refresh the test database with a copy of LIVE.
After your test company is refreshed I will then start to delete the lowest table, and then open GP to the Tcompanymany. I then go to batch recovery. If it is the correct table then the batch recovery should complete the posting of the transaction. If it does not work then I exit GP and refresh the test company again. I then delete the other table and try the batch recovery to very that it posts. After confirmation that the batch posts I then login to the LIVE company and run the delete script on the correct table.

It is important to note that each duplicate transaction posting is different. ALWAYS back up your live environment before running a delete statement in your SQL.