More than two months ago I penned an article titled ‘Horrific QuickBooks Desktop File Errors’ in which I elaborated about a group of errors that we had started to see when people upgraded their files to QuickBooks Desktop 2018, especially QuickBooks Enterprise 18.
At the time of that article I mentioned that one file submitted to us for analysis contained more than 152-thousand corruptions. Since then we have had several files that far exceeded the 150-thousand figure, and we have had a couple of files that exceeded 350-thousand errors.
Many of the files contain ‘target chaining errors’ which are something we saw in QuickBooks files several years ago, but which had almost disappeared (at least in our observations based upon corrupted files submitted to us) in newer versions of QuickBooks desktop until the later releases of 2017 and the early releases of 2018 when we first started seeing those errors raise their ‘dirty little heads’ out of the muck and mire of data files. The illustration below shows an example of the relationship between the ‘Verify Results’ Report (summary and detail) and the related QBWin.log for one type off ‘target chaining error.’
Target-chaining-1_results
Another form of ‘target chaining error’ is what Intuit has terms ‘Version 2’ type errors. An example of both the QBWin.log of a file impacted by this type of error, and an excerpt of a Custom Transaction Detail Report reflecting the ‘Version 2’ designation in the Entered/Last Modified filed (at date: time field) is shown in the illustration below.
Target-chaining-2_results
Intuit tells you that you may see these ‘Target Chaining’ errors after running the Rebuild Utility. In other instances, the presence of errors of this type may again cause the Rebuild Utility to crash with an ‘Unrecoverable Error’. Intuit goes on to tell you that you need to ‘restore a backup’ created prior to the Rebuild that produced the Target Chaining error(s). They then tell you that ‘if a good backup is not available, you will have to create a new company file and re-enter your transactions.’ In other words, ‘don’t bother sending your file to Intuit Data Services.’
Both types are serious errors because the normal ‘Rebuild Data Utility’ which QuickBooks Users and ProAdvisors make use of to resolve errors simply doesn’t work in these two cases. What’s worse, the Rebuild Utility may in fact make matters worse by leading to additional damage or producing even more target chaining errors.
While this is bad enough news, I hate to say that we are starting to see even more serious data irregularities in these newer QuickBooks desktop versions. This is especially true when files were updated to a newer version directly from a version of QuickBooks Desktop older than 1 version. In other words, someone attempting to convert QuickBooks Enterprise 15 directly to QuickBooks Enterprise 18 without proceeding through intervening versions during the upgrade process.
While the upgrade process typically appears to go normally, there is something happening in the data that may not ‘rear it’s ugly head’ for some time, it maybe present but go unnoticed by all but the keenest observer. It may not even impact the financial statements initially, and in fact it may even pass the QuickBooks ‘Verify Data’ utility. That said, I would simply ask ‘how many of you actually run the Verify Data utility after what appears to be a successful upgrade anyway?’
Many people I asked during my Scaling New Heights Super Geek classes responded, “No, if the upgrade says it completed successfully, I never thought I needed to run Verify.”
So here is an example of a problem we recently saw with a client who upgraded from QuickBooks Enterprise 15 to QuickBooks Enterprise 18 directly.
Target_errors_results-3
In this excerpt from the Verify Data section of a QBWin.log file we are looking at a routine check of ‘name information’ in which the various fields for the name that are linked to other tables are ‘out of bounds’ they recite the wrong reference information. In the fields shown in this small excerpt both the ‘terms’ and the ‘vendor type’ fields are corrupted (as shown in the red boxes).
You might not even recognize this error in either the log (if you checked it) or the fields themselves if you opened the specific vendor record. What isn’t shown in this excerpt is there were at least a dozen more corrupted fields of data for this one vendor. Take that one step further, there were more than 12,000 corrupted vendors with similar corruptions in the same file.
I would also mention that the Verify Results while reporting something wrong, the Report itself yielded an error and displayed no error. The most likely cause of this was that the total number of line entries exceeded the capabilities of the file that Intuit uses to report Verify results.
As was, by the time the QuickBooks user recognized something was wrong with their file, and contacted a local ProAdvisor, the file was so bad that both the ‘Verify Data’ utility and the ‘Rebuild Data’ utility would crash whenever they were run.
After sending their file to Intuit Data Services they were told they needed to ‘start a new file’ that the one with these issues was beyond repair.
When the file was submitted to us for analysis it had more than 250-thousand errors. We also felt that it wasn’t viable to attempt to perform a complex repair on the file, and that it would likely be too costly even if the repair was successful.
The most economical solution was for the client to start a new file and re-post a couple of weeks of data since the conversion which had taken place at the end of June for the start of the July 1 new fiscal year.
Their old file (QuickBooks Enterprise 15) which contained none of these errors became their historical file, and they had a new ‘going forward’ file in QuickBooks Enterprise 18 which was prepared for them by a ProAdvisor who was able to import their lists and open transactions without flaws or corruption from the QBES 15 file.