Unexpected keys in EmployeePayrollInfo causing issues deserializing
dteske25 opened this issue ยท 5 comments
Hello! We are having some issues parsing older versions of the QBD SDK with this package.
Some of our clients is sending the following 4 keys under the <EmployeeRet><EmployeePayrollInfo>
key.
When these keys are present, the entire EmployeePayrollInfo
object fails to deserialize, causing unexpected behavior on our platform. Is there a way to allow these extra keys to be present and ignored, or to just be added?
If there's an easy change that I can submit, please let me know.
- IsCoveredByQualifiedPensionPlan - appears on qbxmlops50.xml, qbxmlops70.xml
<IsCoveredByQualifiedPensionPlan>BOOLTYPE</IsCoveredByQualifiedPensionPlan> <!-- PRIVATE, opt, v5.0 -->
- PayScheduleRef - appears on qbxmlops70.xml
<PayScheduleRef> <!-- PRIVATE, opt, v6.0 -->
<ListID>IDTYPE</ListID> <!-- PRIVATE, opt -->
<FullName>STRTYPE</FullName> <!-- PRIVATE, opt, max length = 31 for QBD|QBCA|QBUK|QBAU -->
</PayScheduleRef>
- EmployeeTaxInfo - appears on qbxmlops50.xml, qbxmlops70.xml
<EmployeeTaxInfo> <!-- PRIVATE, opt, v5.0 -->
<StateLived>STRTYPE</StateLived> <!-- PRIVATE, opt, max length = 21 for QBD|QBCA|QBUK|QBAU -->
<StateWorked>STRTYPE</StateWorked> <!-- PRIVATE, opt, max length = 21 for QBD|QBCA|QBUK|QBAU -->
<IsStandardTaxationRequired>BOOLTYPE</IsStandardTaxationRequired> <!-- PRIVATE, opt -->
<EmployeeTax> <!-- PRIVATE, opt, may rep -->
<IsSubjectToTax>BOOLTYPE</IsSubjectToTax> <!-- PRIVATE, opt -->
<PayrollItemTaxRef> <!-- PRIVATE -->
<ListID>IDTYPE</ListID> <!-- opt -->
<FullName>STRTYPE</FullName> <!-- opt, max length = 31 for QBD|QBCA|QBUK|QBAU -->
</PayrollItemTaxRef>
<TaxLawVersion>INTTYPE</TaxLawVersion> <!-- PRIVATE, opt -->
<TaxInfo> <!-- PRIVATE, opt, may rep -->
<TaxInfoCategory>STRTYPE</TaxInfoCategory> <!-- PRIVATE, max length = 100 for QBD|QBCA|QBUK|QBAU -->
<TaxInfoValue>STRTYPE</TaxInfoValue> <!-- PRIVATE -->
</TaxInfo>
</EmployeeTax>
</EmployeeTaxInfo>
- EmployeeDirectDepositAccount - appears on qbxmlops50.xml, qbxmlops70.xml
<EmployeeDirectDepositAccount> <!-- PRIVATE, opt, may rep, v5.0 -->
<!-- BEGIN OR: You may optionally have Amount OR RatePercent -->
<Amount>AMTTYPE</Amount> <!-- PRIVATE -->
<!-- OR -->
<RatePercent>PERCENTTYPE</RatePercent> <!-- PRIVATE -->
<!-- END OR -->
<BankName>STRTYPE</BankName> <!-- PRIVATE, max length = 31 for QBD|QBCA|QBUK|QBAU -->
<RoutingNumber>STRTYPE</RoutingNumber> <!-- PRIVATE, max length = 9 for QBD|QBCA|QBUK|QBAU -->
<AccountNumber>STRTYPE</AccountNumber> <!-- PRIVATE, max length = 25 for QBD|QBCA|QBUK|QBAU -->
<!-- BankAccountType may have one of the following values: Checking, Savings -->
<BankAccountType>ENUMTYPE</BankAccountType> <!-- PRIVATE -->
</EmployeeDirectDepositAccount>
This is strange because all the things you mentioned are marked as "private".
Also, the library is not setup to work with version lower than 13.
Having bad xml is something quite common and we have been fixing the version 13 file. However, this really seems to be something that should not happen?
Are you receiving this in conjunction with the WebConnector? or are you using this differently?
I'm reticent in adding these 4 to the xml because it seems there are plenty of PRIVATE ones that don't show up in your XML.
I would rather have a flag that says "ignore unknown tags" (default false) if we were to get this fixed.
Yep, this is happening when running the web connector. We've tried many different versions of the web connector in our development environment, but were unable to reproduce naturally. However we obtained the raw xml that caused the errors and discovered the presence of these 4 keys. The 1 commonality is that the clients are using Right Networks to host their QBD, but we've been in contact with them as well, and don't understand how or why these keys are showing up.
I would also agree with adding a flag, because as you said, they are marked private.
๐๐ป I'm open for PRs with unit tests :)
I've built out a test case that reproduces the issue. I think the main problem for me is that the unexpected elements are appearing out of order also, causing the rest of the elements to become unknown. I can open the test case as a PR if that's helpful to anyone.
As a whole, I'm not super familiar with xml and haven't found an easy solution to the problem yet. I'll keep digging though.
A "workaround" is now available to handle this in QbXml 2.3.0.
Closing the issue