Fixed for General Release partners on v2020.4.77875
Re-Appearing for pilot partners on v2020.4.77876
Customers using the 2020.4 REST Version
We've had a number of reports of a breaking change to the glClass in the Accounting Export reported by partners who have moved to 2020.4 (REST) version.
In 2020.3 (and prior) version of REST, the gLClass included the Classes from the GL Entries (class mappings), which was used to map Tracking Categories and Classes to Xero and QBO.
In 2020.4. the class is now mapping the expense classification, rather than the expense class. This is resulting in a number of errors stemming from the invalid data being provided for class mapping.
What are we doing about it?
We have logged a ticket with ConnectWise advising the issue.
You may request updates to this ticket and advise if you are affected by this issue:
ConnectWise Ticket: #14402546
Date Reported: Feb 02, 2021
|02 Feb 2021|
Logged a ticket with Connectwise
|11 Feb 2021||Connectwise has confirmed that SOAP will no longer be functional for 2020.4.|
|16 Feb 2021||We had a hotfix release to resolve the Expense issues|
|8 Mar 2021||General Release Partners reporting issue now presenting in Production (after hotfix). Identified issue with SOAP Expense Date not returning expense entries.|
|12 Mar 2021||Further update to hotfix currently being tested for release (Target 15 Mar|
How do we know it's an issue?
Based on our investigations:
Reviewed the Batch Create for failed sync and noted that the glClass is ‘Reimbursable’ rather than the classes.
Reviewed the Create batch for successful sync and the glClass is ‘Eastside’ as expected.
We currently have a work-around by switching the integration back to SOAP version when syncing Non-Reimbursible Expenses.
The issue is persisting with Reimbursable expenses even when integration is set to SOAP.
We've provided additional details to ConnectWise, who are investigating but no further updates at this time.
The only work-around for Reimbursable expenses to post would be to set the account option to 'Warn' rather than 'Halt' on invalid tracking codes. This disables the validation for tracking codes, which is halting the record due to 'Reimbursable' not being a valid tracking code. Allowing the records to post with a warning, will serve the purpose of getting the records to sync.
We'd recommend that this is only switched on temporarily to allow these expenses to post.
Note: Tracking Codes will then need to be manually applied in Xero/QBO after syncing records, and the option (account setting) should be switched off to ensure compliance of tracking codes.