computer bug
Even with Intuit’s prompt response to known issues, new ‘bugs’ associated with the R7 release are showing up almost daily; some minor, some not so.
I have waited a week or so to write this in order to temper my thoughts based upon Intuit’s response to the R7 quagmire. I now find myself compelled to compose something about this situation or else be considered ignorant of what is going on in the ‘real world’ of QuickBooks users.
While Intuit’s intention for the R7 maintenance update was to fix a series of issues that had haunted QuickBooks 2013 ever since it was released, it seems just the opposite occurred. R7 was designed to correct issues associated with the Accountant’s Copy File Transfer service, changing the URL from a ‘quickbase’ site to an ‘intuitcorp’ site; it also was intended to introduce a new feature, QuickBooks ProActive to help with management of computer resources to improve QuickBooks Performance. I have been a critic of Intuit’s past limitations on the use of RAM (cache) memory, although they began offering improvements in this area with maintenance release 5, and QuickBooks ProActive was intended to further these improvements.
Several other ‘fixes’ were included in R7. One change which seemed to be ignored until problems started showing up, was how QuickBooks uses time sheet data; the release notes read: “QuickBooks will no longer display time entries in alphabetical order by Customer: Job on a previously saved timesheet. Time entries will be listed in the order entered.” It is this later sentence in this note that is now driving some users’ “nuts”. Users report that when posting time entries to an invoice, they no longer post in ‘date order’ but are random. In reality they are NOT ‘random’ at all, they are posting in the order they were created (apparently using the internal number for each time entry as the basis to determine creation order) regardless of the time sheet date. While some might consider this an inconvenience, it is a serious issue for people who rely on time entries to generate customer billings, and this situation exists whether using the internal time keeping function in QuickBooks, or if time entries are imported into QuickBooks from other applications (which brings us to another big error in R7). The question regarding this time entry change should be, “why was such a change made, had any users really requested that time entries be posted to invoices in ‘creation order’ vs. ‘date of time entry’ order?” Clearly the bug has bitten a lot of people with this change!
One of the early ‘bugs’ detected with the R7 release was that some 3rd party software which normally integrated with QuickBooks via the SDK (software developer kit) or IPP (Intuit partner platform) interfaces stopped working properly, and in many instanced caused QuickBooks to ‘crash’ with error 00000 37760. In some cases QuickBooks would simply freeze; in other cases the 3rd party application would freeze; and in almost all instances the two programs would loose connection with each other. IPP applications stopped working because, while they do not directly connect to QB, they connect with the QB Sync Manager, and it interacts like an SDK based application. In response to the outcry, Intuit quickly issued a ‘critical patch’ (and ‘pushed’ it out) to resolve this issue; however there were problems with this fix; the critical patch didn’t install automatically, and in many cases it took special steps to implement it (the manual process was complex and some Intuit support personnel seemed confused as to if it was needed). Even with the critical patch installed, many users reported that they were still seeing problems (like, “QBXML components have not been installed”) between their SDK based 3rd party applications and QuickBooks.
R7 was also intended to deal with several ‘encryption/decryption’ errors that have plagued QuickBooks in recent versions, especially as they relate to credit-card numbers. Some users report that the R7 update actually made these problems worse; in some cases credit card data, social security numbers, and other critical information was actually corrupted to the point that some functions would not even work. Users reported having to manually rebuild this data into the file by first removing any traces of these fields, then saving temporary information, then re-editing the fields with the correct data. Clearly data damage of this nature could almost be a ‘lethal bite of the bug’ for some larger clients if 10’s-of-thousands of records were involved.
Apparently, not only is QuickBooks technical support inundated with calls about the R7 release, but advanced level support personnel are taxed with files needing to be repaired. At the same time Intuit Engineers are working to determine how a ‘little fix’ could cause so many new issues, while at the same time attempting to solve problems as they are reported. We can only hope that they will quickly roll-out a ‘bug-free update’ to either ‘cure the bug’ or inoculate against its’ ill effects.
Even with all of Intuit’s efforts, new ‘bugs’ associated with the R7 release are showing up almost daily; some minor, some not so. Just as our perceptions of 'real world insects' vary from one person to another; so do our perceptions of these software bugs. It may turn out that R7 is no ordinary bug at all, but perhaps a ‘Black Widow’!