Call closed and Down Hours calculate incorrect (ECi bug) on EA 17.2 and older
Overview | Samples | Variables | Alert Functionality | Best Practices & Tips | Related Alerts
Overview:
We’ve identified a bug in eAutomate that can result in posting Downhours to a call where it shouldn’t have any, or vice-versa. It happens when a CallType gets changed on a call after the call is moved to OK-to-Invoice Status (and presumably, everyone is done touching it). Obviously these bad numbers can be a problem when your rep is talking you up to your customer (it’s presented prominently on our QBR and Customer Service History reports) or if you publish these values for reps to use when talking to folks who aren’t customers yet. This alert will advise you that such a call has been completed, and send whoever closed the call a handy write-up about what they did wrong and how not to do it again.
Run Schedule: Daily
Type of Output: Email
* * *
Sample
This alert still in development, no samples available until in Beta Status
* * *
Variables
To Be Determined
* * *
Alert Functionality
The issue is in SCReports.DownHours in eAuto versions 17.2 and older, which is supposed to only be populated when the associated CallType tracks back to the ‘CM’ Corrective Maintenace CallTypeCategory. We’re seeing a LOT of calls in the field which either have DownHours posted when they shouldn’t (not a CM call) or have zeroes posted when there ought to be a value (call is CM and dates/times cross over ServiceHours per the relevant SLACodes). What we’ve found is that if a Call has its CallType changed after the Call is moved to OKB/OK-to-invoice Status that recalculation of the values is NOT done. DownHours calculations look like they take place every time a labor entry is entered and when the Call is moved to OKB, but changes after the move to OKB (if not changes to a labor record) do not trigger a recalculation. It’s not good practice but it’s a fact of life that a lot(!) of client agents flip CallTypes after the move to OKB, and the result for clients heavy in this practice is hundreds of additional DownHours recorded on large contracts.
* * *
Best Practices & Tips
eView:
To determine if this is an issue for you, create a custom eView from Service Calls (Invoiced) to see Down Hours posted on Corrective Maintenance and non-Corrective Maintenance calls. Anything with Down Hours should also have Response and Repair Times posted.
You will need to be sure column names of Call Type Category, Down Hours, Response Time, and Repair Time are part of the eView (add any needed):
1. Start with Service Calls (Invoiced) eView, and select New:
2. Name your eView and Import any needed columns:
3. Be sure to use Sync with columns option on Filters tab:
Down Hours should only be calculated on CM (Corrective Maintenance Category Calls). If there are no down hours when you do have response and repair time on CM Calls, then you have an issue.
Use filter of Call Type Category contains CM and Down Hours equals 0 :
Also run eView for non CM Category Calls to see if those have Down Hours along with Response and Repair Hours. If you receive results, that also indicates an issue:
Use filter of Call Type Category does NOT equal 0 and Down Hours is greater than 0 :
The ONLY correction/fix for these is to VOID the service call and RE-INVOICE. Please see THIS LINK on Best Practice for voiding of service calls to ensure you re-invoice is in correct GL Period.
* * *
Related Alerts
None at this time
* * *
0 Comments