Provides notice of potential data entry errors on Service Calls
95% of the new clients we take on have inaccurate data in contract profit reports, mostly due to things like a technician entering a kilometer reading instead of miles. Then you have 97,000 miles showing as a cost on a contract. This alert is meant to catch where either users ignored the popup warnings for these values you setup in Tools/Options/Service Calls/Additional Options OR you do not have any values setup for the popup warnings.
Alert fires at time of call closure (tech must actually complete the call by selecting "complete") and if still not fixed, then again at time of invoice. It's important that these are fixed before they are invoiced as you will have to void and re-bill if you wait until invoiced.
We will alert you if an invoiced call exceeds any of the numbers you input for the corresponding values above. This alert will ignore calls that have status "Scheduled" until they are closed, at which time it will then check the sanity numbers..
Run Schedule: every 15 minutes
Type of Output: Email
* * *
1. Invoice Number - You will see the invoice number if it's been invoiced otherwise it says UnInvoiced, Let us know if you are getting these too late.
2. Trigger Action - Indicates what variable setting triggered alert (i.e. Response Hours, Travel Time, Labor, Mileage) per your variable settings
* * *
VariableX: enter (whole numbers only) quantity of TRAVEL HOURS in excess of to be notified of
VariableY: enter (whole numbers only) quantity of LABOR Hours in excess of to be notified of
VariableZ: enter (whole numbers only) quantity of MILEAGE in excess of to be notified of
VariableW: enter (whole numbers only) quantity of RESPONSE HOURS in excess of to be notified of (ONLY CORRECTIVE MAINTENANCE calls considered for Response Hours)
Variable1: indicate YES/NO if you'd like alert to notify if Arrival Time=Departure Time
Variable2: limit BRANCH NUMBER(s) (not branch name) for alert to consider
* * *
-The creator is the person who invoiced the service call. However if using eAgent to auto complete invoicing of service calls, then it will stamp the creator as the user id that is logged into eAgent.
If ID219 catches a call and it's completed but not invoiced, then the "creator" is whoever completed the call. eAutomate stores the information for all un-invoiced calls in a series of temporary tables, then whoever 'created' the record is the Creator.
The invoice step creates a new set of records from these temporary tables and then deletes the temporary records when it creates the permanent records in the new tables. More clients are having e-agent auto invoice service calls therefore we lose visibility of who actually "closed/completed" the call because the "invoiced" records are created by an eAgent user id.
**Please note, eAuto 16.1.5 bug on response time (corrected in subsequent versions): The response times are not calculating correctly when the service call is set on hold and the on hold code has the checkbox checked for 'calculate response time using release date and time'.
* * *
Best Practices & Tips:
This report helps you find data entry errors that can cause profitability to be wrong. A technician or dispatcher may fat finger an odometer reading giving you a mileage of 9,234 miles. This may not show up in your balance sheet because most people use the same account for revenue and cost so they offset, but when you run profitability it will be hugely wrong. This alert will find errors like this.
Response Time: when call logged to when tech arrives
Actual Hours vs. Labor Hours: Actual Hours is from arrival to completion. The difference between labor hours and actual hours is labor hours is what is billed on the service call (this can be overridden by the user or by eAuto depending on how you have your bill codes set up for incremental billing) and actual hours is the actual hours from arrival to completion.
Void the Call and change the data to the correct information then re-invoice.
Please note Response Time shown comes directly from eAutomate. So if it is off, then review the Service Call to ensure tech dispatch time is correct. If it is, then make sure your Company Hours set in eAuto are correct and/or the the tech's eAuto Employee Record reflects the Service Hours he/she works.
Reason why this would not make any difference
For time to have an impact you have to have a set burden rate. You really need to have a burden rate in every employee file so you are charging the time that technicians spend on site to the contract. Otherwise all your contracts will have Zero cost for time.
(See THIS LINK on Calculating Burden Rate.)
Where do I find out what GL’s are being affected?
To find out where the cost of labor and payroll expense offset are done. This is all under the Billing account cost. You can find this in lists and codes. If they are the same they will offset and the net GP entry is Zero. Most companies do this. This still allows for tracking of burden rate to the contract without creating additional work for the Accounting staff.
Mileage and Travel
Mileage and travel is also done in the Billing Account Code and the same rule applies if they are both offsetting each other.
The difference is that Travel and Mileage expense are set company wide in the options settings:
We suggest to use the burden rate to travel cost and then set the per mile to your mileage reimbursement or $0.50 for company vehicles.
Stop Bad Data on Service Calls:
How to stop bad data on invoicing on $0 service calls
Within the eAgent Task Auto Invoice Service Calls, you can set to NOT auto invoice if any such warnings exist. These must first be set in eAuto via Tools \ Options \ Service Calls \ Additional Options. We suggest setting these to match your ID219 subscription:
* * *
ID1 - Call Dispatched (not arrived) between W & X hours
ID2 - Dispatched/OnSite After Hours
ID17 - Technician On-Site too long
ID18 - Guaranteed Response Time Could be Missed
ID93 - Pending 'CM' calls that are within (W) minutes of due time with EscalationAlert within X (customer down)
ID223 - CM Category Calls for Today where arrival time was after DueTime (ignores Reschedule Calls)
* * *