Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2023 Release Wave 1Check out the latest updates and new features of Dynamics 365 released from April 2023 through September 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
Hello Dynamics GP Community!
In this article we will be covering the known issues that we've had reported with Microsoft Dynamics GP as well as the resolutions available for these issues.
With any upgrade, we recommend reviewing all documentation and known issues prior to the upgrade process and always recommend to perform a test upgrade to insure you will have minimal downtime when it comes time for your production upgrade.
There is currently one known upgrade issue that you may encounter when upgrading Microsoft Dynamics GP to the U.S. 2020 Year-end Update released 11.19.2020
You may encounter the following error message:
Violation of PRIMARY KEY constraint 'PKPM00204'. Cannot insert duplicate key in object 'dbo.PM00204'
This will not happen for all customers it depends on a certain data condition. What utilities is doing is if we find the 1099 vendor with a box type that goes to the new 1099-NEC we are moving this for you in utilities. In our scripts during utilities we found that we duplicated the last set of scripts so it is trying to run it again when really the data was already converted. There is no way to fix this prior to the upgrade, we need to let utilities fail so all your PM data is converted correctly. There is no script to identify which companies this will happen on, you just need to let it try the update and continue on with steps below.
IF THE UPGRADE IS ALREADY IN THE FAILED STATE ON THE PM00204 TABLE FOR EACH COMPANY THAT FAILS:
1. Run this script in SQL Server Management Studioselect * into PM00204TEMP from PM00204
2. Delete the contents of the PM00204 table so it is empty for the upgradeDelete PM00204
3. Run this script against the Dynamics/ System database.
4. Kick off the upgrade and it will complete.
5. Move the data back to the PM00204 table
insert INTO PM00204
(VENDORID,TEN99TYPE,YEAR1,PERIODID,TEN99BOXNUMBER, TEN99AMNT, TEN99FRNORUSDTL, TEN99STATECD,TEN99STATIDNUM, TEN99TAXEXMTCUSIPNUM, TEN99DIRSALECB,TEN99STATNMBR,TEN99FATCAFILEREQ)
SELECT VENDORID,TEN99TYPE,YEAR1,PERIODID,TEN99BOXNUMBER, TEN99AMNT, TEN99FRNORUSDTL, TEN99STATECD,TEN99STATIDNUM, TEN99TAXEXMTCUSIPNUM, TEN99DIRSALECB,TEN99STATNMBR,TEN99FATCAFILEREQ from PM00204TEMP
**If you are just upgrading to GP 2016 year end and staying there, you will not run into this issue, the problem only seems to occur when you are upgrading to 18.3.1200 (year-end)**Have the users spot check 1099 vendors especially ones they expect to move to NEC type vendors based on box information.
Once all is completed and data verified run
DROP TABLE PM00204TEMP
The following is the list of upgrade issues we've encountered in the past for Microsoft Dynamics GP. If anything new is reported we will be sure to get them added here as well.
During an upgrade to Microsoft GP 2018 R2 or later, you may have encounter an error regarding the ASIEXP86 table.To workaround this issue you can perform the following steps:
This issue should be fixed with the release of the Microsoft GP 2018 R2 January 2019 hotfix.
We convert several tables that have account framework information stored in them. If the the account framework tables in the company database do not match the SY003001 and SY00302 table in the Dynamics system database, the upgrade will fail.
Please run the Account_Framework Validation script from the upgrade guide to validate your tables prior to the upgrade.
If results are returned, please work with your partner or contact technical support to discuss options for those tables. We do have other account framework tables that can be changed, but these are a few of the main tables checked when it comes to account framework.
The AA Budget Tree Balance (AAG00904) table contains the records for each budget in Analytical Accounting. If there are budget date records in the AAG00904 table that do not exist in the aaDateSetup (AAG00500) table, the upgrade will fail and the following error occurs.
AAG00904 135 [Microsoft][SQL Server Native Client x.x][SQL Server] Cannot insert the value NULL into column 'YEAR1', table 'xxxx.dbo.AAG00904'; column does not allow nulls. Update fails.
If you are migrating to a new SQL server in addition to the upgrade, you can restore your database to the new SQL server and start your upgrade. Please refer to KB 878449 for the steps covering migration to a new SQL server.
Once the database are restored to the new SQL server, you must change the database compatibility.
If there are detail records in the POP10110 and POP30110 that do not have a matching header record in the POP10100 and POP30100, the upgrade may fail on those tables.
Run the Invalid_Records_POTables script from the upgrade guide to validate all detail records have a matching header record. If results are returned, you can either delete the detail records or run checklinks in the current version of Dynamics GP you are running.
When launching Microsoft Dynamics GP, the server drop down list may be blank. The server drop down is the ODBC DSN that is required by Dynamics GP in able to connect to your SQL server databases.
If the ODBC DSN is an older version or a 64-bit DSN, it will not appear in the list. Please make sure you have a 32-bit ODBC DSN created using Native Client 10.0 or newer driver.
If you use our Workflow for GL/PM/RM Batches, Purchase Orders, Vendor Approvals, Credit Limit Overrides, Sales Quotes, Employee On-boarding, etc., all workflow documents must be final approved prior to the upgrade; no documents can be pending.
The upgrade does check for this and will stop utilities and provide a report showing what documents need to be approved.
When you launch GP Utilities for the upgrade, most of the processing is performed on the SQL server.
If you happen to take focus away from GP Utilities, it may appear to stay white and show "not responding". Please do not close out of Utilities; the upgrade is still running - give the upgrade time to continue working.
If you feel the upgrade is hanging or locked up, please start a SQL Server Profiler trace to review activity.
When you launch GP Utilities to start the upgrade, if you have overlapping fiscal periods it will hang on the Multicurrency Setup Master table. Run the script below to determine if you have an overlapping fiscal periods and correct the periods prior to starting the upgrade process.
SELECT DISTINCT a.YEAR1, a.PERIODID, a.PERIODDT, a.PERDENDTFROM SY40100 a JOIN SY40100 b ON a.PERIODID <> b.PERIODID AND a.PERIODDT <= b.PERIODDT AND a.PERDENDT >= b.PERIODDT AND ( a.PERIODID <> 0 AND b.PERIODID <> 0 )ORDER BY YEAR1, PERIODID
If you have duplicate Attachment_ID values for Payables Transaction record and a Payables Transaction History record in the CO00104 and CO00105 table you may immediately ecounter an error.
The following statement during the upgrade causes this issue:
IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = Object_id(N'[dbo].[CO00104]') AND Objectproperty(id, N'IsUserTable') = 1) UPDATE CO00104 SET BusObjKey = Replace(BusObjKey, '0\PM\Payables Transaction History', '0\PM\Payables Transaction') WHERE BusObjKey LIKE '%0\PM\Payables Transaction History%'
The error occurs when the upgrade attempts to update an BusObjKey value of "0\PM\Payables Transaction History\XXXXXXXXXX" to be "0\PM\Payables Transaction\XXXXXXXXXX". When it does this, the records with the same BusObjKey and Attachment_ID values can result in a duplicate records causing a primary key error that is visiable in the DEXSQL.LOG.
You can run the following script to workaround this issue:
The scripts will compare the BusObjKey and Attachement_ID for any potential issues and will create a cleanup script in the result tab.
Note: As always, ensure that you have a full working backups of your system and company databases before running the generated cleanup script. The script identifies what records are potential going to cause a duplicate error - you can then make a decision to use the generated script to remove these records.
We have found an issue with the Dynamics GP upgrade code which causes the EHW20200, EHW30200 and EHW40200 table to fail an upgrade if there is any data in these tables at all. These tables are part of the Employee Health and Wellness module (Prod ID 4955), which is one of the four modules that make up the Human Resources and Payroll Suite.
The issue is when the upgrade attempts to insert the data back into these tables, which both receive a new INACTIVE and EHW_Discount column added - it is trying to put the data back into the temp table where the data already exists instead of putting the data back into the newly upgraded tables.
If you run into this upgrade error you can get around this by running the steps below:
Be sure to check back our Microsoft Dynamics Upgrade Blog Series Schedule to review upcoming blog posts related to upgrading Microsoft Dynamics GP and other helpful resources.
Business Applications communities