This is actually something we're currently investigating.
If you capture this issue in a dexsql.log, most likely you'll find that an error stating 'number of results doesn't match table definition' or similar, and the cause being a dex procedure for the PM00200 table, i.e. zDP_PM00200SS_1, for example.
We've seen various things fix this type of issue, ruling out third parties, using the Repair process to generate a 'new' GP directory completely, but what seems to be the more common fix is doing the following:
1. Export all your modified reports, if not everything, from the Customization Maintenance window in Dynamics GP, into a package file.
2. Open the package file in NotePad or another text editor.
3. Search for any field value showing as 'DBA' in reference to the 'PM_Vendor_MSTR' table, which is the PM00200 table.
This will look something like this:
= Table "PM_Vendor_MSTR"
{
~Fields
{
- TableField "DBA"
}
}
Change this to be 'VENDDBA', which is the new column that is added to the PM00200 table via the year-end update for both Dynamics GP 2016 and 2018/18.3.
***NOTE: Do NOT do a 'replace all' changing every 'DBA' to 'VENDDBA' as we only want to change those field values related to the PM00200/PM_Vendor_MSTR table.
= Table "PM_Vendor_MSTR"
{
~Fields
{
- TableField "VENDDBA"
}
}
4. Save changes to the package file, then import the package file back into Customization Maintenance, which should overwrite the reports with the updated information. At that point, you can test this issue with the AP checks to see if the issue is resolved or not.
If it doesn't resolve the issue, we may need you to open a support case so we can look at the issue with you.
As mentioned, it's something we've begun to see and are still investigating. While we haven't been able to re-create in-house, we have been able to do so using a package file from a customer experiencing this same issue with AP checks.
Please let me know if you have any questions.
Thank you