ID67 - Call closed with invalid Down Hours Overview & Sample (In Development)

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

Click to Subscribe 


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

*  *  *


This alert still in development, no samples available until in Beta Status


*  *  *


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


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.

If you determine the call category is right, but down hours is not, then you can just void the invoice, fix the down hours manually on the service report tab and re-invoice it.
If you determine the call category was changed in error, then void service invoice, un-check the ok to invoice box, flip the call type to the proper one and mark it ok to invoice again. Then re-invoice it once you've verified the down hours was corrected on the service report tab.



*  *  *

Related Alerts

None at this time


*  *  * 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Please sign in to leave a comment.
Powered by Zendesk