Reported Date is populated, by default, when you enter Customer Details.
It is used to indicate the time the Customer called in or reported the Incident. It is important as the Create Date only indicates when the Incident was saved to the DB. The Create Date therefore does not give a true indication of when the call actually started.
It is used in SLM as the default field for use with Response Time Service Targets as you can measure the difference between this date and say the Create Date to indicate the time taken to populate the Incident etc giving you a response time.
Are there any cases where Reported date field is not being populated with any value?
Ideally Reported date is same as Create date and is populated as soon as the ticket is submitted.
that is not quite correct. It will be populated by workflow on submit if it is not present but it has a purpose as explained above, so ideally it is not the Create date.
It will be cleared if you clear the Customer information.
This is set from other fields (hidden etc) dependant on your actions, so it would be hard to determine why it is not being set.
It is also used in the Dialog window mappings, i.e. when you use the Process Flow bar, so if there is an incorrect mapping on one of these Close Actions this could be removing the value etc.
You would need to turn on logging to find out what is clearing this field
I can't seem to reproduce this issue, but there are a couple of tickets that don't have Reported date in them. It only occurs when ticket status is moved from New to Closed (First call resolve). I tried to do this but still I'm getting a value in Reported Date field.
I'll do further invetigation on this.
What happens if Service Desk receives user email to create new incident at 9:00am.
Then Service Desk creates a new incident at 9:10am.
Or can we enable the Reported Date field so that Service Desk can input the timestamp freely?
I am extending this discussion,
Same as this post in our Incident Mgt Application, we have found Responded Date as blank for some incidents , When we debugg this further we come to know that, Responded date gets populated when Response is set to Yes by a workflow,(Correct me if I 'm wrong)..the incidents having blank responded date has Response field as No..But in our log we didn't find out action which is setting this as "No" also it is not default value for that field..
In addition to this, I want to know why Responded Date is same as Reported date in many cases,For this when we investigate we found 2 filters out of which one sets Reported date as Responded date..it runs on Submit action(HPD:INC:SetRespondedDate_526_Set) and other one sets Responded date as TIMESTAMP..It runs on Modify action(HPD:INC:SetRespondedDate_525_Set) Can anyone guide in this context as it seems to be confusing for me?
Any help will be appriciated...
Thanks in Advance...
ok, lets see if I can explain this for you.
As mentioned, Reported Date will be auto-populated by workflow when the customer information is entered (Classification tab). This will then be pushed to the Dates tab when the request is saved. This can be changed before you save the Incident.
Responded Date is populated when the request first gets saved and is indicative of the date the Incident is recorded (also thought to be on when the request is first Assigned, but does not seem to be the case). This again can be manually changed/set, but will be auto populated on saving of the request.
Based on this, if you leave both dates blank the system will populate the Reported Date with the date/time the Customer information was entered and then set the Responded Date to this value (Reported Date) on saving of the request. If you enter a Responded Date, the system will use this value when saving a request.
See below for where it is set by workflow (related to SLM), and now other factors come into play.
Service level data pushed from back-end SLM forms. If set to Yes, the ticket must be responded to. This is particularly important in the case of a response-time goal, where a blank Response (SLA Responded) field might indicate that the service target goal has been missed. NOTE: Not applicable if SLM is not installed.
Snippet from the User Guide:
The service target response time applies when an incident is recorded from an email, fax, voicemail, or web self-serve request. In this case the Responded Date is blank until someone indicates that the incident has been responded to. When support staff record an incident, the Responded Date is set to the date that the incident is recorded.
So if you have SLM installed, and Service Targets defined etc, the behavour is different as the Response field is populated from SLM by workflow. This explains why you would be seeing this set to Yes/No if you have this module installed.
BMC has a fix for this. It happens only when someone enters an Incident and immediately puts it in pending (prior to saving). The fix has to be adjusted for AR System 7.5 since SET field no longer used. See KA312950.