QuickBooks Multi-instance and SDK Complications in Intuit Field Service Management

by

The ability of QuickBooks Accountant and Enterprise users to open more than one company file using the ‘multi-instance’ feature can at times present problems associated with 3rd party applications that make use of the QuickBooks SDK.  We have known that you cannot use any SDK applications while QuickBooks has multi-instance functional (more than 1 company file open); however, even after you close the secondary instance you may still have problems with any SDK application that remained active as a ‘windows process’ during the multi-instance session.

As an example, I am going to illustrate the ‘sync function’ associated with Intuit’s own Field Service Management (FSM) for QuickBooks Enterprise (which we know is actually a product of Corrigo).  When you launch FSM, a web-based application, and then launch QuickBooks, the sync function starts as a windows process on your computer and connects to the designated company file.  Depending on your settings within FSM you either sync the two sets of data manually, sync only the customers:job manually, or you automatically sync certain data (behind the scenes) on a periodic basis you determine.  To my knowledge there is no way to manually kill this sync process without opening Windows processes and actually ending the Corrigo Sync engine; thus begins the problem associated with launching a secondary instance.

Now let us assume that even though the FSM-sync is running in the background you open a secondary instance of QuickBooks, and this secondary company is NOT supposed to have any tie to FSM. By design QuickBooks does not permit the sync function (or any SDK functions) to perform normal operations as long as multi-instance is operational; the two applications simply do not communicate with each other, and that is fine, since that is the way QuickBooks intended it to work. 

But now we close the primary company (the one which normally works with FSM) and the secondary company (the one that should not link with FSM) remains open.  Now the company that had been running as the secondary instance becomes the ‘primary’ QuickBooks instance.  The next time that the sync process starts, or as soon as the sync function recognizes this as a different file, it attempts to initiate the SDK-interface and gain access to the wrong company file.  Therein lies the problem, and it continues even if you simply ignore the SDK-interface, and even if you subsequently close the primary instance. 

So the problem seems to have evolved into something more sinister. It appears that FSM-sync is ‘stuck’ thinking that it must ‘connect’ to the file it was never intended to connect to. Even if you launch QuickBooks again and open the original company that normally connects to FSM, the FSM-sync will not reconnect to that company unless you manually go into the Windows processes and kill the sync engine, and then ‘restart’ everything.  This can be a real pain, especially for users who are uncomfortable with doing anything in the ‘windows process’ window. If you are a user who must continually work in two QuickBooks files, one of which should be connected to FSM, you have real issues.

Resolving the issue:

I found that the best way to resolve this problem is to simply initiate the SDK interface in the secondary company and then select the option “Do Not Allow this Application to Read or Modify this Company File”, as shown in this article’s headline illustration.

Once the company file becomes inaccessible to the FSM-sync, the application ‘looks on down the road’ (so to speak) for the QuickBooks Company file it is intended to connect with. If the proper QuickBooks file remains running after a multi-instance has ended, FSM then connects properly and normal QuickBooks to FSM activities can proceed, including the normal behind the scenes sync on the scheduled basis. Even if the proper company remains closed, as long as the original SDK interface settings between FSM and the correct QuickBooks file were configured to permit FSM to access the file even when closed, the sync will resume and continue as scheduled.  

(Note: SDK means ‘software developer kit’, and the SDK-interface, for purposes of this limited technical discussion, refers to the connection dynamics shown in the illustration within this article.)

Corrigo, is the registered trademark of Corrigo, Inc. of Tualatin, OR.

Windows, is a registered trademark of Microsoft Corporation of Redmond, WA.