Earlier this year we published an article by Bill Murphy about a variety of problems with the QuickBooks Enterprise Advanced Inventory feature. One of the problems was a file corruption issue (when using the multiple inventory location feature of QuickBooks Enterprise with Advanced Inventory) that could not be repaired. Intuit has finally identified the problem, and we have information on how to resolve it.
In that article Bill describes a new type of data corruption which prevented the QuickBooks’ Verify function from completing. Using the rebuild function in QuickBooks would not resolve the problem. Usually when you run into this kind of issue you would send the file to Intuit Data Services, or a private QuickBooks data repair specialist (such as Bill at RRR, Ltd.). The problem was that neither Intuit or these repair specialists could repair these files.
Here’s an example of the error that you would see in the QBWIN.LOG file:
After that article was posted Bill and I opened a discussion with the Intuit QuickBooks Enterprise staff to see if there was a way that this could be resolved. Bill provided them with sample data files, and Intuit’s Advanced Inventory team leaders and members of their Data Services and Development team worked on identifying the cause. Recently Intuit contacted Bill and I to report that the cause of the error had been identified and that there was a way to repair files that show this problem.
According to Bill:
“This type of error apparently results when a Purchase Order ‘header’ transaction has a Null (blank) value in the “Ship To” field which should correspond to one of the Advanced Inventory Sites. This probably occurs when a site has initially been selected and associates the line items with that site; but subsequently a line item is added or changed and the “Ship To” is accidently deleted (perhaps while attempting to change it). When the transaction is saved, the prior line items retain the ‘original site’ and one or more line items now have no site assigned to them. The ‘header’ is also without an assigned site in the “Ship to” even though the ship to address field may in fact display an address.”
So, the error is caused by the user editing an existing purchase order when multiple locations are involved. QuickBooks Enterprise itself is not causing the error by itself (although it DOES allow the problem to occur). The QuickBooks verify and rebuild functions do recognize this as an error (correctly), and generate the message:
Verify.c (###): CHECKPOINT: ####: Day Date Time (Real line ####): This transaction #### [the internal id #] has mixed sites in targets which verify/rebuild cannot fix, Please contact support
Bill went on to say:
“While we cannot be certain as to the exact sequence of events that set this error in motion, now that we understand the real causative mechanism, professional file assistance can identify the exact transactions involved and fix these errors with either a correction or transaction deletion/replacement. With either of these repairs, the transaction will subsequently pass the file Verify routine.”
Can It Be Repaired?
So, can you fix this problem if it occurs? Well, sure, but it isn’t exactly a straight-forward issue. The QBWin.log file is just a starting point. The error message identifies the internal transaction id #, not the purchase order number that you would see in Enterprise. This internal value is not visible in the Enterprise user interface. The number can only be found within the internal transaction and link tables which relate the Master (transaction header) and Target (transaction line item) records. Here’s an example of the link table.
Since this is information that isn’t readily available to the typical user, self-repair is almost impossible. So, what can you do? You can work with a knowledgeable repair professional (such as Bill), or send your data to the Intuit Data Services team who should be able to repair the file now that the cause has been identified.
In discussing this error, and its’ fix, Bill told me that he was surprised how such a simple little thing could not only render the file unverifiable, but also have made it almost impossible for complete diagnosis that might have led to professional repair earlier. He told me that he and Shannon Tucker had spent weeks, earlier this year, working together on one of these errors without ever figuring it out.
Now that Intuit has identified the problem they should be able to prevent it and repair it easily. It is a complicated issue, so it may take Intuit some time to get a fix out. I’m hoping that future releases of QuickBooks Enterprise will not only include a fix to prevent the error from happening, but also include an update to the verify and rebuild functions so that a corrupted file can now be repaired easily. Note that this problem occurs in both Enterprise 12 and Enterprise 13.
Intuit has established KB Article SLN64349 for this error – you can subscribe to that notification to receive an email message when a fix is available. You can also bet that QuickBooks and Beyond will have information on an update to fix this problem as soon as it is available.
I would like to thank Bill Murphy for providing the technical information for this story. I couldn’t figure out the details by myself. It is also important to thank Catherine Fisse, Intuit’s Senior Product Manager for QuickBooks Enterprise, for taking a special interest in this problem and focusing the resources at Intuit on this issue.