“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.
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.
I’m sure that this has happened to everyone, you follow the steps and you launch your web client web page. Then, after you log in you receive the dreaded error, “A problem occurred creating a session error.” Often the first response is to repair the web client and proceed to check the local certificate. This is followed by checking the services. And alas, nada. None of these processes fix the error.
The problem is not the web client install, but the added feature on the actual Microsoft Dynamics GP installation. One misconception about installing the web client is that multiple Runtime installs exist. You have the Web Client Runtime and the Web Services Runtime. The Web Client Runtime is often missed because it hides in the Microsoft Dynamics GP install.
1. Web Client Runtime: On the Web Client server go to Programs and Features, select Microsoft Dynamics GP 2015 (Desktop Client Install), click Add/Remove Features and check if Web Client Runtime is installed. If this runtime is not installed edit and then try logging into the Web Client.
2. Web Services Runtime: The second Runtime is located in the GP installation. When you open the installer you will see the Web Services Runtime.
I’m certain that this has taken place in many businesses. Someone logs in for the day and when they print a report or a check, they receive this error. Or they receive a new computer with a fresh copy of Microsoft Dynamics GP and when they try to print a report, the error stops them. This error is interesting because it can happen in different circumstances. It is one of three problems, a missing reports dictionary, a missing 3rd party, or a communication issue with the reports share. Every time I see this error I take specific troubleshooting steps.
1. If the install is a new install on the PC, I check the reports dictionary by going to Tools>> Customize >> Customization Maintenance. If there are no reports stored here, my next step would be to identify the storage location of the reports. On new installs, the reports need imported or pointed to the shared location. If they are on a share, I would point the GP installation to the share.
2. If there are reports visible and they will not print, I navigate to the shared reports folder while logged in as the user. This verifies that the user has access to the share. If you cannot navigate to the shared file location, it may not be a problem with Microsoft Dynamics GP. The permissions to the folder the reports dictionary writes to could have communication issues. Anytime there is a communication issue, I recommend having the server checked over by your IT department. If you are a technical consultant, I would recommend that you take a more in-depth look at why the communication issue appeared. In past situations, I identified communication issues because disks malfunctioned or the operating system corrupted. The result was the server being decommissioned and replaced. Another example, I discovered that they had Cryptolocker on the file share and the virus encrypted the dictionary within the shared folder.
3. Check the form to verify that the correct security is set by going to Tools >> Setup >> System >> Alternatives/Modified Forms and Reports. If you had a 3rd party and removed it, this could have no selection. In one example, I had no selections in this window. By selecting the default Microsoft Dynamics GP report in this window, the report could print again.
Microsoft Dynamics GP Deleting User Error “Deleting the login failed for an unknown reason. Contact your SQL Server administrator for assistance.”
￼Every time I have encountered this is when a user is set up to a specific company database. To resolve this follow these steps:
- Go to your SQL and verify that the user has a SQL login setup. If they do then follow
- Expand your company database
- Expand Security
- Expand Users
- Right-click on the user you are trying to delete and select Delete. This will remove the user’s SQL profile from the database and any schema’s that are causing the error.
- Repeat for all company databases
- Repeat in the Dynamics database
NOTE: DO NOT REMOVE THE OVERALL SQL LOGIN only under each specific database
Log back into Microsoft Dynamics GP and remove the user through the normal user setup. This will remove the user from Microsoft Dynamics GP and also SQL.
This error has been the most troublesome for me in the past. Typically of you try searching the error you will get pointed to KB article 943948. What I have found is that this is caused when you run an integration and Microsoft Dynamic GP seems to disappear and Integration Manager freezes or gets closed down integration. I have also seen this occur after an error and the user tries to re-run the integration.
What is occurring is that Integration manager and Microsoft Dynamic GP still has processes running in the background. If you go into task manager and look at the running processes you will see multiple for Microsoft Dynamics GP for the user trying to run Integration Manager. You have two solutions, either go into task manager to stop the processes and test again or have the user reboot.
Sometimes just stopping the services does not resolve the error and a reboot is still required. If a user is logged into a terminal server it is important to verify that they fully log off the server and simply does not disconnect.
In Microsoft Dynamic GP, there is a direct scanning button that is available. For the direct scan button to activate you must have a WIA driver installed. If it does not detect the driver it will appear grayed out (as the screenshot above shows).
I ran into an issue recently where I needed to have the users RDP into a terminal server and be able to utilize an activate scan button. Microsoft redirect did not work and I tested several third-party scanning redirect software programs, such as TSscan and scanredirect. Neither of these products worked to activate the scan button because they installed a TWAIN driver on the terminal server. I had tested about 6 scanning redirection options before I found one product that installed a TWAIN and WIA driver on the server side and pulled the scanner’s default scanning options into the server. This product is Scanner for Remote Desktop. Here is their guide to their product with instructions on how to install.
I was not paid to represent this product and earn no money placing this on my blog. I found that this product assisted in resolving a problem that took me over a month to find a solution. If you have another scanner redirection product that also installs a WIA driver on the server I would be more than happy to edit this post and add it.
With Microsoft Dynamics GP permissions come from two different types of accounts. There are local accounts and GP accounts. Local accounts are setup on a domain in Active Directory. GP accounts are setup within the GP programs.
The permissions for excel reports pulls from Active Directory and not Microsoft Dynamics GP. Specifically, it is an active directory account setup in SQL and set DYNGRP and rpt_power_user for it to access the account.
First login to SQL and expand security. Under the security right click on login and select ‘new login…’. After you select new login you will be able to see the option to search for a login. This search will allow you to search in Active Directory. After you add the new user under the general tab, then select the user mapping. Under the user mapping, select all the databases that the user should be able to run excel reports in and add the permissions DYNGRP and rpt_power_user. If you do not want to provide them the rpt_power_user role, then you would be able to select the rpt_%rolename% that best fits your company’s security policy. This can also be matched to their GP logins permissions.