Julie, Thanks for pointing this out! Curiously, I found that my recent Help Desk 6.0 installation had this same bug you described, but I could not find it on my now inactive Help Desk 5.5 installation. The filter on the old 5.5 app used the correct value of $Arrival Time$ rather than $DATE$ to set the 'zTmpIntArrivalTime' field. It didn't look like the filter had been modified from the OTB version either.
--Thomas ----- Original Message ----- From: Julie L Kanakanui JLKANAKA Newsgroups: gmane.comp.crm.arsystem.general To: [email protected] Sent: Wednesday, August 01, 2007 8:51 AM Subject: Resolved time of Tickets - HOURS TO RESOLVE field ** Okay, here's what I dug up from my notes in March 2006 when I found out about this "bug" from Tech Support. It is actually all about the "Hours to Resolve" calculation (so if any others out there know more about this, chime in!) Hours to Resolve should be reflecting in Hours the time from submission of the request to the time it is placed in a Status of Resolved. There is a known product issue with the workflow that performs this calculation. The Filter that does this is called HPD:HPD-CalcHoursToResolve. Out of the box, this filter is configured to set a field called zTmpIntArrivalTime with $ DATA$ which is incorrect. The filter should be setting this field with $ Arrival Time$. Because this is incorrect, the values set in the Hours to Resolve are incorrect. This filter needs to be modified to set the correct value in zTmpIntArrivalTime for the Hours to Resolve to function properly. So.... if you can see in the HPD:HPD-CalcHoursToResolve filter that zTmpIntArrivalTime is set to $DATA$, then you can hopefully fix the reporting problem by setting it instead to $ArrivalTime$ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
