On a Bill Add QuickBooks SDK is dividing the quantity by the unit of measure set (30) instead of multiplying it.

Question

The issue on a bill add is that the unit of measure is dividing the quantity by thirty instead of multiplying by thirthy. Here is the request and the response on a bill Add:

<OUTGOING>
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE QBXML PUBLIC '-//INTUIT//DTD QBXML QBD 12.0//EN' >
  <QBXML>
    <QBXMLMsgsRq onError = "continueOnError">
      <BillAddRq requestID = "1">
        <BillAdd>
          <VendorRef>
            <FullName>ABC</FullName>
          </VendorRef>
          <APAccountRef>
            <FullName>211100</FullName>
          </APAccountRef>
          <TxnDate>2014-10-19</TxnDate>
          <DueDate>2013-12-10</DueDate>
          <RefNumber>724335265</RefNumber>
          <Memo></Memo>
          <ItemLineAdd>
            <ItemRef>
              <FullName>597007541</FullName>
            </ItemRef>
            <Desc>SPIRIVA 18 MCG HH CAP  30</Desc>
            <Quantity>0000010.00000</Quantity>
            <UnitOfMeasure>30 Pack</UnitOfMeasure>
            <Cost> 269.18</Cost>
            <Amount>2691.80</Amount>
          </ItemLineAdd>
        </BillAdd>
      </BillAddRq>
    </QBXMLMsgsRq>
  </QBXML>
</OUTGOING>
<RETURNS>

  <QBXML>
    <QBXMLMsgsRs>
      <BillAddRs requestID="1" statusCode="0" statusSeverity="Info" statusMessage="Status OK">
        <BillRet>
          <TxnID>8246-1395341818</TxnID>
          <TimeCreated>2014-03-20T14:56:58-05:00</TimeCreated>
          <TimeModified>2014-03-20T14:56:58-05:00</TimeModified>
          <EditSequence>1395341818</EditSequence>
          <TxnNumber>2967</TxnNumber>
          <VendorRef>
            <ListID>80000E65-1395254081</ListID>
            <FullName>ABC</FullName>
          </VendorRef>
          <APAccountRef>
            <ListID>80000056-1383071992</ListID>
            <FullName>Accounts Payable Wholesaler</FullName>
          </APAccountRef>
          <TxnDate>2014-10-19</TxnDate>
          <DueDate>2013-12-10</DueDate>
          <AmountDue>2691.80</AmountDue>
          <RefNumber>724335265</RefNumber>
          <IsPaid>false</IsPaid>
          <ItemLineRet>
            <TxnLineID>8248-1395341818</TxnLineID>
            <ItemRef>
              <ListID>80000B29-1386299840</ListID>
              <FullName>597007541</FullName>
            </ItemRef>
            <Desc>SPIRIVA 18 MCG HH CAP  30</Desc>
            <Quantity>0.33333</Quantity>
            <UnitOfMeasure>30 PACK</UnitOfMeasure>
            <OverrideUOMSetRef>
              <ListID>80000003-1386168088</ListID>
              <FullName>30 PACK (30)</FullName>
            </OverrideUOMSetRef>
            <Cost>8075.4</Cost>
            <Amount>2691.80</Amount>
          </ItemLineRet>
        </BillRet>
      </BillAddRs>
    </QBXMLMsgsRs>
  </QBXML>

</RETURNS>

Screen shots from QuickBooks can be found at https://www.dropbox.com/sh/w051ozhkvzfu8qq/ieHCp0CMZY

Any help is appreciated. Thanks.

Answer 1

Update QuickBooks to the latest release and try again.

Answer 2

I don't know if this is a 'bug' or if it is working as intended, but I can explain what is happening.

The base unit for your UoM set is Each. You have a conversion of 30 called "30 Pack". However, when you add the item to the bill, it enters in the 10 as a Quantity of Each, and then applies the conversion of 30 Pack.

You can see this if you manually try entering the transaction in QuickBooks. On a new bill, select the item and enter 10 as the quantity. When you are entering the quantity, QuickBooks will be prompting you if you want 10 30 Pack, or 10 Each. The SDK is using 10 Each. After you select 10 Each, then select your Unit of Measure. You'll see that it has the conversion from 10 each to a 30 pack, which would mean that it would need to divide.

I personally think this is a bug, but Intuit may have a different opinion. For now, the only thing I can suggest is that you use the base unit when supplying your quantities. If you then add the Unit of Measure, it will show as you're expecting.