I seem to recall I had a similar problem a while back and the solution I came up with was to use business time based on the create date. Might work for you.
$PROCESS$ Application-Bus-Time-Add "$Create Date$" 0 0 "Business Time Holidays" "Business Time Workdays" Mark -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Thursday, June 13, 2013 2:01 PM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters Good point, I realized after I sent my reply that the previous problem was using active links and not filters. I will have to check out the total filter count for that form since I hadn't looked at that yet. -Rick ___________________________ Rick Westbrock QMX Support Services -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Thursday, June 13, 2013 9:51 AM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters As you are working with Filters the time zone will not be an issue (as you are processing the keyword on the server in both cases) I only noticed it when I had a form with a lot of Filters that took a while to process Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Thursday, June 13, 2013 11:17 AM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters ** Interesting! I will have to give that a try. The problem doesn't happen to all first-call resolution tickets but I don't know what percentage of them have this problem so it might take a while to replicate in the test environment. I am not sure if that would cause problems if the user is in a different time zone than the server; the only reason I mention that is we had resolved a totally unrelated issue by switching keywords like that due to the time zone difference. -Rick ___________________________ Rick Westbrock QMX Support Services -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, June 12, 2013 20:28 PM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters ** One thing I have seen is $TIMESTAMP$ is only set at the beginning of the filter cycle. If you want the real time inside a filter you need to use $SERVERTIMESTAMP$ Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, June 12, 2013 3:57 PM To: arslist@ARSLIST.ORG Subject: Create Date later than $TIMESTAMP$ from filters ** In light of the other thread about Create Date vice Modified Date I ran into something along similar lines today an wondered if anyone else has seen something similar. We have a set of filters that put $TIMESTAMP$ into date/time fields, one per status value (i.e. if there are five different status values there will be five date/time fields). The qualifications on the filters are such that if the status changes to that value (i.e. if ticket changes to status value 2 then the Status 2 Date/Time field is used) and sets $TIMESTAMP$ into the corresponding date/time field. The strange behavior that I am seeing is that these status date/time values are all exactly one second older than the value in the core Create Date field. My assumption is that $TIMESTAMP$ is evaluated during the filter processing but the Create Date field is not populated by the server until probably the very instant before the record is actually committed to the database; if filter processing takes too long then the clock might tick over into the next second. Has anyone else run into this dilemma? It is only a problem for me because in reporting any tickets that have say the Work In Progress date/time less than the Create Date field then it is out of compliance and we have to massage the data for multiple tickets after the fact. In a recent check I found that there were 796 records where the status date/time fields were less than the Create Date but only four of them were more than one second older (obviously due to unrelated issues). The obvious quick & dirty fix for this (which may not be optimal) is to modify the filters to set the status date/time fields to $TIMESTAMP$ + 1 so that they either match the Create Date or might possibly be one second later but I wanted to investigate the root cause before touching any existing code. -Rick ARS 7.6.04 SP2/Windows/MS-SQL ___________________________ Rick Westbrock QMX Support Services _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" ________________________________ Important: This email is intended for the above named only and may be confidential, proprietary, and/or legally privileged. If this email has come to you in error, you must take no action on it, nor may you copy or show it to anyone. Please contact the sender and delete the material from any computer. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
