Today's #TipTuesday is about Checklinks, specifically about a message a user may get when running 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? In my client's case, it was 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 to see what the errors are and investigate further in case any data was removed that shouldn't have been. Checklinks *can* be destructive, unintentionally, but yes, the process can remove records that are otherwise valid. Running it in a test company allows a user 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 could 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 was 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 is 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, and deletes it but the record number didn't get removed for some reason.
How can a user check this?
This happens to be about the RM Key File, it's RM00401 in the company database(s). Compare the results of what's there in Prod vs. Test and the user should see some similar "bad" data before it is run in Prod 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!
