If you have ever had an interrupted payables check run in Dynamics GP and decided to do a little troubleshooting yourself, you’ve probably come across KB 852064, which talks about troubleshooting the interrupted payables transactions. One of the steps in this article that often causes a lot of confusion is running the Check Links process.
What is the Check Links process, and what does it do?
Check Links was originally created as a method of maintaining data integrity between the tables. In the olden days, this was necessary because the Index Sequential Access Method database platforms on which Great Plains had been designed to run did not support referential integrity. These days, the function is much the same – the process looped through the inserted tables to check that the referential integrity is correct. If it finds orphaned records, it can sometimes delete these, under certain circumstances. This is why Microsoft always recommends to having a backup prior to running. Another reason to be cautious is if you have third-party products installed – Check Links has, on occasion, been known to corrupt data in third-party tables because it deleted what would, under normal circumstances, be an orphaned record, but the reference was stored in a third-party table. In addition, the process can also create records if it finds a reference in one table without a corresponding reference in another table. Sometimes this works more smoothly than other times – perhaps you’ve had an issue where you ran Check Links and a blank batch ID was created. This is usually because there’s a damaged record in one of the transactional work tables. Check Links finds this record, but because it’s damaged, it doesn’t have the requisite information to create a full batch record, and so a partial record is created.
With regards to the payables transactional tables, there are certain things that the Check Links process will do when run against the Payables Transaction Logical Files and Payables History Logical Files. These are the tables which store your work/open and historical payables transactions, respectively, so you would run Check Links against these when you had an issue with a payables transaction (as opposed to a vendor record, for instance, which is a different table).
Courtesy of one of the Senior Support Engineers over at Microsoft, below is a list of the effects you can expect when you run Check Links against one or both of these tables:
• Deletes orphan child records (meaning tables where header record does not exist for things like the Distributions)
• Creates missing PM Key record for existing header records
• Moves Fully Paid Transactions to History when certain conditions are met
• Does NOT recreate missing apply records
• Does NOT delete orphan apply records
• Updates the DCSTATUS field in the PM00400 (ex: 0 to 3) (1 – work, 2 open, 3 history)
As you can see, the Check Links process can have beneficial effects, but it won’t do everything for you. It is typically recommended that you run Check Links on a regular basis (say, monthly) as part of your maintenance procedures, provided you’ve verified that it doesn’t negatively affect your data under normal circumstances. This helps to make sure that if you do have any irregularities, they are caught and fixed before the situation gets too serious. As with everything, though, take a backup first!
If you have questions about running Check Links in your system, or if you’d like more information on recommended maintenance procedures for your Dynamics GP system, please don’t hesitate to reach out to me at jnorberg@ktlsolutions.com.
https://support.microsoft.com/en-us/help/852064/how-to-continue-a-check-run-that-was-interrupted-in-payables-managemen
