InvoiceAddRq fails for unknown reason - etl

Question

I hope I stay in line here, I don't want to waste your time.
I developed a simple app that extracts customer invoice data from a database and writes xml requests to load the invoice data into QuickBooks. It works well. I've run into and fixed a dozen or so quirks and glitches along the way; it's in production about a year.
While loading today's invoices into QuickBooks, one failed.
There were no objectionable characters or oddities in the data of the failed invoice; I compared it to other invoices and found very similar data that was successful; I verified the ListID values for each entity; I am stumped.
If anybody can help with this, I will appreciated it greatly.
Here's the xml that failed today (the only change is that I blocked a couple of names):
FAILED InvoiceAddRq:
<?xml version="1.0"?>
<?qbxml version="8.0"?>
<QBXML>
<QBXMLMsgsRq onError="stopOnError">
<InvoiceAddRq requestID="16012816370245509">
<InvoiceAdd>
<CustomerRef><ListID>3E00001-1139583887</ListID></CustomerRef>
<ARAccountRef><ListID>380000-1137509930</ListID></ARAccountRef>
<TemplateRef><ListID>B0000-1142608867</ListID></TemplateRef>
<TxnDate>2016-01-28</TxnDate>
<RefNumber>60125008</RefNumber>
<PONumber>AI600292569</PONumber>
<TermsRef><ListID>20000-1137508984</ListID></TermsRef>
<ShipDate>2016-01-25</ShipDate>
<Other>XYXYX PLASTICS</Other>
<InvoiceLineAdd>
<ItemRef><ListID>20000-1139578831</ListID></ItemRef>
<Desc>RECOVERING 1/25DEL. 1/26 # 11:57 AM EST – POD XYXYX</Desc>
<Quantity>1</Quantity>
<Rate>480.79</Rate>
<Other1>6</Other1>
<Other2>3466</Other2>
</InvoiceLineAdd>
</InvoiceAdd>
<IncludeRetElement>TxnID</IncludeRetElement><IncludeRetElement>TimeCreated</IncludeRetElement><IncludeRetElement>RefNumber</IncludeRetElement>
</InvoiceAddRq>
</QBXMLMsgsRq>
</QBXML>
I don't see anything wrong here. I compared this with the xml for many successful InvoiceAdd requests that occurred before and after this one. Then I tried it again for the insanity check (same result).
Below I'll post a similar invoice as a successful example.
SUCCESSFUL InvoiceAddRq:
<?xml version="1.0"?>
<?qbxml version="8.0"?>
<QBXML>
<QBXMLMsgsRq onError="stopOnError">
<InvoiceAddRq requestID="160128164851801">
<InvoiceAdd>
<CustomerRef><ListID>80000915-1294766937</ListID></CustomerRef>
<ARAccountRef><ListID>380000-1137509930</ListID></ARAccountRef>
<TemplateRef><ListID>B0000-1142608867</ListID></TemplateRef>
<TxnDate>2016-01-28</TxnDate>
<RefNumber>60125011</RefNumber>
<PONumber>2200166200</PONumber>
<TermsRef><ListID>20000-1137508984</ListID></TermsRef>
<ShipDate>2016-01-26</ShipDate>
<Other>X&Y MEHOOPANY </Other>
<InvoiceLineAdd>
<ItemRef><ListID>20000-1139578831</ListID></ItemRef>
<Desc>UNABLE TO DELIVER DUE TO THE WEATHER 1-22DEL. 1-25, POD. AXYXYX BXYXYXY #14:30</Desc>
<Quantity>1</Quantity>
<Rate>148.60</Rate>
<Other1>1</Other1>
<Other2>3</Other2>
</InvoiceLineAdd>
</InvoiceAdd>
<IncludeRetElement>TxnID</IncludeRetElement><IncludeRetElement>TimeCreated</IncludeRetElement><IncludeRetElement>RefNumber</IncludeRetElement>
</InvoiceAddRq>
</QBXMLMsgsRq>
</QBXML>
Thanks in advance.
edit: I forgot to mention that the error was very generic
"QuickBooks found an error when parsing the provided XML text stream."
Source:QBXMLRP2.RequestProcessor.2

Answer 1

Ok, I found the cause. The logged message cited an invalid byte "(–)". The dash character was bouncing my Invoice. I had previously looked into invoices using a dash and found many were successful loaded using the same method. What I had failed to notice was that the dash characters were different in all of the successful invoices I found except 1.
The failed xml includes – or, if you prefer, – or "En dash" instead of the normal ascii dash "-" (-).
The SDK validator doesn't flag it as a problem. Also, 1 invoice that included an "En dash" had previously loaded successful; I can't explain that.
I use character substitution tables to deal with the requirements (or idiosyncrasies) of Xml, QbXml, and the database (Oracle). Instead of changing my encoding, I'll substitute - for all occurrences of – (and —, "Em dash", for that matter). This worked for the previously failing invoice.
Thanks again to WilliamLorfing for the help.