Today’s #TipTuesday is about Checklinks, and specifically about a message you may get if you run file maintenance against Sales > Receivables Open Transaction Files. Some general parts of this blog may apply to other errors in checklinks but I’ll focus on this one message for now to keep it simple.
File Maintenance Error Message
The exact error message looks like this and the text is: “ The transaction for this keys record is missing. The keys record has been removed.”.
What does this mean?
The message sounds kind of scary, right? What I’m going to show you isn’t the answer to all of the messages of this sort, but in my client’s case, it was actually fine.
There’s a good article by fellow MVP Mariano Gomez describing how checklinks works. The short version is checklinks is intended to find and resolve issues in tables such as removing orphaned records etc. where the application code, for one reason or another, did not do that itself in the first place.
My recommendation is to run checklinks in a test company or test environment before running it in production. The reason is you will be able to see what the errors are and investigate further in case there is any data removed that shouldn’t be removed. Checklinks *can* be destructive, unintentionally, but yes, it can remove records that are otherwise valid. Running it in a test company gives you the opportunity to compare the results of that process with data in the corresponding production company to see if it makes sense.
In my specific case, the errors made sense, once I saw the before and after data! Because I ran this in a test company before running it in production, I had the ability to compare the contents of the RM00401 table in Test vs. Prod and here’s what I found. The records removed, were all of the top set in this screenshot, which were all orphaned records (no BCHSOURC, no TRXSORCE, etc.).
Here is the corresponding after-checklinks screenshot. The number of records in the top section of the previous screenshot are the same records in the error message that were removed. Some were duplicates, with a DCSTATUS of 1 as well as another record with a DCSTATUS of 2. What likely happened is the docs that were duplicated were posted but the process didn’t remove or update the DCSTATUS 1 record like it should have. For the records that were simply orphans, they could be docs that were deleted before posting. It’s pretty common that a user starts a transaction and gets sidetracked, deletes it but the record number didn’t get removed for some reason.
How can you check this yourself?
This happens to be about the RM Key File, and when you look up that table name, you find it’s RM00401 in the company database(s). Compare the results of what’s in there in Prod vs. Test and you should see some similar “bad” data before you run it in Prod that corresponds with what’s in Test’s reports after running the sample checklinks process.
The tables in checklinks are findable via Resource Descriptions in GP (Dynamics GP menu > Tools > Resource Descriptions > Tables). If I look at Sales > By Table Display name. this is what I see, with the corresponding SQL table name right there for me to query.
That’s it for this post… enjoy!