I'm using the QuickBooks SDK 13.0 to interface with our QuickBooks Enterprise 14.0 via QBXML. It hasn't been an easy road, given the poor documentation and lack of good examples online, but I have made inroads towards the completion of my project, which is to integrate a homegrown inventory system to QuickBooks Advanced Inventory. However, I couldn't find even traces of a solution for the problem I now describe:
Task: To retrieve a list of inventory items from QuickBooks
Method: I am using QBXMLRP2.IRequestProcessor5.ProcessRequest() in order to process a ItemInventoryQueryRq request file.
If I issue only one request for all 5,033 inventory items, everything works perfectly, but that single request takes a while to complete and return. So I implemented an "iterator" to get 100 products at a time and give the application time to "breathe" in between requests. The first call works fine and looks like this:
<?xml version="1.0"?>
<?qbxml version="13.0"?>
<QBXML>
<QBXMLMsgsRq onError="stopOnError">
<ItemInventoryQueryRq requestID="1" iterator="Start">
<MaxReturned>100</MaxReturned>
<OwnerID>0</OwnerID>
</ItemInventoryQueryRq>
</QBXMLMsgsRq>
</QBXML>
When I process this request, I get the first 100 items and the remaining count is 4933, which is correct:
...
<ItemInventoryQueryRs requestID="1" statusCode="0" statusSeverity="Info"
statusMessage="Status OK" iteratorRemainingCount="4933"
iteratorID="{ea9ae5fa-d1b5-4719-9f77-dd4ac27e1eed}">
...
It's from this point on that the problem happens...
The next request looks like this:
<?xml version="1.0"?>
<?qbxml version="13.0"?>
<QBXML>
<QBXMLMsgsRq onError="stopOnError">
<ItemInventoryQueryRq requestID="2" iterator="Continue"
iteratorID="{ea9ae5fa-d1b5-4719-9f77-dd4ac27e1eed}">
<MaxReturned>100</MaxReturned>
<OwnerID>0</OwnerID>
</ItemInventoryQueryRq>
</QBXMLMsgsRq>
</QBXML>
At this point I'm expecting the next 100 items, and a remaining count of 4833. However, the processor skipped 100 items, gave me the next 100, and returned a remaining count of 4733:
...
<ItemInventoryQueryRs requestID="2" statusCode="0" statusSeverity="Info"
statusMessage="Status OK" iteratorRemainingCount="4733"
iteratorID="{ea9ae5fa-d1b5-4719-9f77-dd4ac27e1eed}">
...
Subsequent calls do the same: skip 100, return the next 100, and the counter decreases by 200:
...
<ItemInventoryQueryRs requestID="3" statusCode="0" statusSeverity="Info"
statusMessage="Status OK" iteratorRemainingCount="4533"
iteratorID="{ea9ae5fa-d1b5-4719-9f77-dd4ac27e1eed}">
...
<ItemInventoryQueryRs requestID="4" statusCode="0" statusSeverity="Info"
statusMessage="Status OK" iteratorRemainingCount="4333"
iteratorID="{ea9ae5fa-d1b5-4719-9f77-dd4ac27e1eed}">
...
<ItemInventoryQueryRs requestID="4" statusCode="0" statusSeverity="Info"
statusMessage="Status OK" iteratorRemainingCount="4133"
iteratorID="{ea9ae5fa-d1b5-4719-9f77-dd4ac27e1eed}">
...
And so on. It looks like the processor is sending each request twice, every time, and I only get the result of the last call.
In troubleshooting the problem, I found the following log file that gets updated every time I make a call to the processor: %AppData%\Local\Intuit\QuickBooks\Log\14.0\QBWin.log
This file shows the following two lines for every call made to the processor:
oasdkrequestprocessor.cpp (397) : CHECKPOINT: 5024: Fri Mar 28 13:39:56 returning from ProcessXMLRequest, result = 0
oasdkrequestprocessor.cpp (397) : CHECKPOINT: 5024: Fri Mar 28 13:39:57 returning from ProcessXMLRequest, result = 0
Which reinforces my suspicion that ProcessRequest is causing a duplicate call to be issued.
Am I doing something wrong or missing something in my calls? Any help is appreciated.
====> Update (4/1/2014): It turns out this behavior was not present on a second machine I tested, so I uninstalled all Intuit products from my development PC, used a cleanup tool to get rid of old Registry entries and associated DLLs, and then reinstalled only QuickBooks Enterprise 14.0 and the SDK 13.0. Applied the latest updates, and everything is good now. Too bad I lost a day of my life trying to figure out what was going on...
