Known Issue: Class is now mapping the Expense classification rather than the Expense Class (2020.4 CW Version)

Status

Fixed for General Release partners on v2020.4.77875
Re-Appearing for pilot partners on v2020.4.77876

Who's affected

Customers using the 2020.4 REST Version

Issue

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

 Updates 
02 Feb 2021

Logged a ticket with Connectwise

11 Feb 2021Connectwise has confirmed that SOAP will no longer be functional for 2020.4.
16 Feb 2021We had a hotfix release to resolve the Expense issues
8 Mar 2021General Release Partners reporting issue now presenting in Production (after hotfix). Identified issue with SOAP Expense Date not returning expense entries. 
12 Mar 2021Further update to hotfix currently being tested for release (Target 15 Mar


How do we know it's an issue?

Based on our investigations: 

Full:  v2020.4.77492

Reviewed the Batch Create for failed sync and noted that the glClass is ‘Reimbursable’ rather than the classes.

Full: v2020.3.75788

Reviewed the Create batch for successful sync and the glClass is ‘Eastside’ as expected.

Workaround

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.

S
Suzette is the author of this solution article.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.