What is the correct structure for adding MULTIPLE Time Activities in QBXML (Quickbooks Desktop API)? - quickbooks

Question

When communicating with Quickbooks Desktop (via the Quickbooks Web Connector) from my web application, I can successfully add INDIVIDUAL time entries to Quickbooks using the following XML (QBXML) structure:
<?xml version="1.0" encoding="utf-8"?>
<?qbxml version="6.0"?>
<QBXML>
<QBXMLMsgsRq onError="stopOnError">
<TimeTrackingAddRq requestID="100">
<TimeTrackingAdd>
<TxnDate>2022-10-22</TxnDate>
<EntityRef>
<ListID>8000000F-1661995835</ListID>
</EntityRef>
<CustomerRef>
<ListID>80000007-1654551468</ListID>
</CustomerRef>
<ItemServiceRef>
<ListID>80000008-1654552326</ListID>
</ItemServiceRef>
<Duration>PT1H0M</Duration>
<PayrollItemWageRef>
<ListID>80000009-1654190217</ListID>
</PayrollItemWageRef>
<Notes>Test Note</Notes>
<BillableStatus>Billable</BillableStatus>
</TimeTrackingAdd>
</TimeTrackingAddRq>
</QBXMLMsgsRq>
</QBXML>
For reference this conforms to the
Intuit API specification for TimeTrackingAdd requests.
HOWEVER, when I try to formulate a BATCH request (i.e. send multiple time entries in a single request) I get an error from Quickbooks:
"QuickBooks found an error when parsing the provided XML text stream."
The QBXML for my failing batch request is similar to the above: I simply repeat the <TimeTrackingAdd> section with another valid (individually working) time entry:
<?xml version="1.0" encoding="utf-8"?>
<?qbxml version="6.0"?>
<QBXML>
<QBXMLMsgsRq onError="stopOnError">
<TimeTrackingAddRq requestID="100">
<TimeTrackingAdd>
<TxnDate>2022-10-22</TxnDate>
<EntityRef>
<ListID>8000000F-1661995835</ListID>
</EntityRef>
<CustomerRef>
<ListID>80000007-1654551468</ListID>
</CustomerRef>
<ItemServiceRef>
<ListID>80000008-1654552326</ListID>
</ItemServiceRef>
<Duration>PT1H0M</Duration>
<PayrollItemWageRef>
<ListID>80000009-1654190217</ListID>
</PayrollItemWageRef>
<Notes>Test Note</Notes>
<BillableStatus>Billable</BillableStatus>
</TimeTrackingAdd>
<TimeTrackingAdd>
<TxnDate>2022-10-23</TxnDate>
<EntityRef>
<ListID>8000000F-1661995835</ListID>
</EntityRef>
<CustomerRef>
<ListID>80000007-1654551468</ListID>
</CustomerRef>
<ItemServiceRef>
<ListID>80000008-1654552326</ListID>
</ItemServiceRef>
<Duration>PT2H0M</Duration>
<PayrollItemWageRef>
<ListID>80000009-1654190217</ListID>
</PayrollItemWageRef>
<Notes>Test Note</Notes>
<BillableStatus>Billable</BillableStatus>
</TimeTrackingAdd>
</TimeTrackingAddRq>
</QBXMLMsgsRq>
</QBXML>
The QB XML Validator tool (provided in the QuickBooks SDK v15.0) is of little help. It validates the first individual transaction but chokes (I think internally) on the BATCH operation with "Error during validation: D, Conversion from string "Line: 31 LinePos: 21 Src Text:" to type 'Double' is not valid."
I thought that this was the correct way to batch requests - it seems that this approach is being used for 'ADD' requests on similar entities (like invoices).
I've hit my head on this for 2 days and can find no example anywhere on the web for a batch TimeTrackingAdd request or concrete information on how to batch Quickbooks Desktop 'Add' requests in general. I believe that it's important to batch these requests to efficiently process user timesheets and to provide timesheet atomicity, i.e. that if a timesheet fails ALL of the time-entries that it is comprised of will also not be created in Quickbooks - saving a potentially messy cleanup where some time-entries (within a single user weekly timesheet) succeed and others fail.
I will award points for a working QBXML sample or any comments that help me solve my problem.

Answer 1

I have found the answer to my own question with the help of 2 answers to related questions on stack overflow by Keith Palmer.
It seems that, for some entities like payments, multiple "ADD" requests, are repeated at the <ReceivePaymentAdd> level (i.e. not the <ReceivePaymentAddRq> parent level).
See: Adding Multiple Payments using QBXML
However, for other entities like sales orders, we make multiple "ADD" requests repeating the <SalesOrderAddRq> (parent) level (i.e. not the <SalesOrderAdd> child level). This appears to be the case for Time Tracking additions.
See: Multiple Orders in Sales Order Add request in qbxml
Any insights into what still appears to me as an QBXML inconsistency would be welcome!
Note also that the shape of the XML response loosely mirrors the shape of the request. Said another way, the Quickbooks response for a time-tracking ADD cannot be parsed in the same way as a time tracking QUERY - the response has a different XML hierarchy.
In case it helps other users (and for reference), here's a working example for adding multiple time entries:
<?xml version="1.0" encoding="utf-8"?>
<?qbxml version="9.0"?>
<QBXML>
<QBXMLMsgsRq onError="stopOnError">
<TimeTrackingAddRq requestID="100">
<TimeTrackingAdd>
<TxnDate>2022-10-23</TxnDate>
<EntityRef>
<ListID>8000000F-1661995835</ListID>
</EntityRef>
<CustomerRef>
<ListID>80000007-1654551468</ListID>
</CustomerRef>
<ItemServiceRef>
<ListID>80000008-1654552326</ListID>
</ItemServiceRef>
<Duration>PT2H0M</Duration>
<PayrollItemWageRef>
<ListID>80000009-1654190217</ListID>
</PayrollItemWageRef>
<Notes>Startup Edmonton > Pre-design Notes</Notes>
<BillableStatus>Billable</BillableStatus>
</TimeTrackingAdd>
</TimeTrackingAddRq>
<TimeTrackingAddRq requestID="100">
<TimeTrackingAdd>
<TxnDate>2022-10-24</TxnDate>
<EntityRef>
<ListID>8000000F-1661995835</ListID>
</EntityRef>
<CustomerRef>
<ListID>80000007-1654551468</ListID>
</CustomerRef>
<ItemServiceRef>
<ListID>80000008-1654552326</ListID>
</ItemServiceRef>
<Duration>PT3H0M</Duration>
<PayrollItemWageRef>
<ListID>80000009-1654190217</ListID>
</PayrollItemWageRef>
<Notes>Startup Edmonton > Pre-design Notes</Notes>
<BillableStatus>Billable</BillableStatus>
</TimeTrackingAdd>
</TimeTrackingAddRq>
<TimeTrackingAddRq requestID="100">
<TimeTrackingAdd>
<TxnDate>2022-10-25</TxnDate>
<EntityRef>
<ListID>8000000F-1661995835</ListID>
</EntityRef>
<CustomerRef>
<ListID>80000007-1654551468</ListID>
</CustomerRef>
<ItemServiceRef>
<ListID>80000008-1654552326</ListID>
</ItemServiceRef>
<Duration>PT4H0M</Duration>
<PayrollItemWageRef>
<ListID>80000009-1654190217</ListID>
</PayrollItemWageRef>
<Notes>Startup Edmonton > Pre-design Notes</Notes>
<BillableStatus>Billable</BillableStatus>
</TimeTrackingAdd>
</TimeTrackingAddRq>
<TimeTrackingAddRq requestID="100">
<TimeTrackingAdd>
<TxnDate>2022-10-26</TxnDate>
<EntityRef>
<ListID>8000000F-1661995835</ListID>
</EntityRef>
<CustomerRef>
<ListID>80000007-1654551468</ListID>
</CustomerRef>
<ItemServiceRef>
<ListID>80000008-1654552326</ListID>
</ItemServiceRef>
<Duration>PT5H0M</Duration>
<PayrollItemWageRef>
<ListID>80000009-1654190217</ListID>
</PayrollItemWageRef>
<Notes>Startup Edmonton > Pre-design Notes</Notes>
<BillableStatus>Billable</BillableStatus>
</TimeTrackingAdd>
</TimeTrackingAddRq>
<TimeTrackingAddRq requestID="100">
<TimeTrackingAdd>
<TxnDate>2022-10-27</TxnDate>
<EntityRef>
<ListID>8000000F-1661995835</ListID>
</EntityRef>
<CustomerRef>
<ListID>80000007-1654551468</ListID>
</CustomerRef>
<ItemServiceRef>
<ListID>80000008-1654552326</ListID>
</ItemServiceRef>
<Duration>PT6H0M</Duration>
<PayrollItemWageRef>
<ListID>80000009-1654190217</ListID>
</PayrollItemWageRef>
<Notes>Startup Edmonton > Pre-design Notes</Notes>
<BillableStatus>Billable</BillableStatus>
</TimeTrackingAdd>
</TimeTrackingAddRq>
<TimeTrackingAddRq requestID="100">
<TimeTrackingAdd>
<TxnDate>2022-10-28</TxnDate>
<EntityRef>
<ListID>8000000F-1661995835</ListID>
</EntityRef>
<CustomerRef>
<ListID>80000007-1654551468</ListID>
</CustomerRef>
<ItemServiceRef>
<ListID>80000008-1654552326</ListID>
</ItemServiceRef>
<Duration>PT7H0M</Duration>
<PayrollItemWageRef>
<ListID>80000009-1654190217</ListID>
</PayrollItemWageRef>
<Notes>Startup Edmonton > Pre-design Notes</Notes>
<BillableStatus>Billable</BillableStatus>
</TimeTrackingAdd>
</TimeTrackingAddRq>
</QBXMLMsgsRq>
</QBXML>