- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-12-2024 10:52 PM
Hi Team,
I'm working on calaculating the business duration between the created_at and closed_at. But It is not updating the correct time. The business rule script is as below.
(function executeRule(current, previous /*null when async*/) {
var schedule = '090eecae0a0a0b260077e1dfa71da828';
var startDate = new GlideDateTime( current.opened_at);
var endDate = new GlideDateTime( current.closed_at);
var gschedule = new GlideSchedule(schedule, 'Australia/Melbourne');
gschedule.load(schedule);
var durationInHours = gschedule.duration(startDate, endDate).getDurationValue();
gs.info(durationInHours);
try{
current.calendar_duration = durationInHours;
current.update();
gs.info('record updated'+ current.calendar_duration);
}
catch(err){
gs.info('Error:'+ err.message);
}
})(current, previous);
But the caculations are wrong. Refer below image.
Can you find a fix for it?
Thanks a lot.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-14-2024 03:33 AM
Then I think everything is correct an I also know where the confusion is coming from. Your schedule counts work days of 9 hours. That means that your 1st, 2nd and 4th example have 5 hours on day one, and 7 hours on the last day (just rounding the numbers). Between July 30th and August 13th there are whole working days. Total = 93 hours.
The 3rd example has 5 hours on day one and 5 hours on the last day and in between 7 whole days of 9 hours (according to the schedule) and that ends up being 73 hours.
Your duration field takes days | hours | minutes | seconds and 1 day is 24 hours (so that is not a "real" day like Monday or Tuesday).
93 hours, divided by 24 hours will end up being in the high 3 days (almost 4) and 73 just over 3 days.
Your "Duration" field is showing you the total hours taken in days | hours | minutes | seconds. Not the number of days from July 30th to August 13th.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-13-2024 01:21 AM
Can you also share the schedule, because it could very well be correct, if there are working hours, weekends and holidays defined in the schedule.
Next to that: what is your requirement here? ServiceNow provides this OOB by using SLA definitions or metrics.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-13-2024 02:56 AM
Hi Mark,
The schedule I'm using is: 8-5 weekdays excluding holidays which I believe is a OOB one.
The Requirement is to calculate the hours spent to close a task type ticket only 8-5 weekdays excluding holidays
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-14-2024 03:33 AM
Then I think everything is correct an I also know where the confusion is coming from. Your schedule counts work days of 9 hours. That means that your 1st, 2nd and 4th example have 5 hours on day one, and 7 hours on the last day (just rounding the numbers). Between July 30th and August 13th there are whole working days. Total = 93 hours.
The 3rd example has 5 hours on day one and 5 hours on the last day and in between 7 whole days of 9 hours (according to the schedule) and that ends up being 73 hours.
Your duration field takes days | hours | minutes | seconds and 1 day is 24 hours (so that is not a "real" day like Monday or Tuesday).
93 hours, divided by 24 hours will end up being in the high 3 days (almost 4) and 73 just over 3 days.
Your "Duration" field is showing you the total hours taken in days | hours | minutes | seconds. Not the number of days from July 30th to August 13th.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark