I want to calculate number of working days between two dates (record field) and use the output as a custom field in the record. Getting stuck while trying to use calworkDays in a!customFieldDateDiff function. Can anyone please help
Discussion posts and replies are publicly visible
You can use the calworkDays() function in a sync-time custom record field.
Hi Stefan thanks for your response but in my use case I need to calculate workdays between a record field and today's date.. So cant do it in sync-type custom record field can you please suggest any possible solution to do this in real time custom record field.
I think this is not supported at real time.
okay stefan, is there any other way round , The exact use case is that user will enter number of days a case is open in the interface, then we need to query all the cases present in the record which are open for the entered number of days excluding the weekends and holidays based on "created On" date-time type field which is present in record.
For example if the user enters 5, then we need to return all cases which are opened for 5 business days.
Can this be done using a!queryRecordType in the interface itself.
Then, why not take that number entered by the user, add it to the current date respecting business days and store that. Then this would work like a due date.
a!queryFilter( field: 'recordType!{95b6b60f-3baf-445b-8ac8-ad1c6aabc820}CMS Cases.fields.{d29ddafb-ab89-4da7-8e24-13e050f348cd}createdOn', operator: "between", value: { datetime( year(today() - ri!busniessDaysOpenFilter-1), month(today() - ri!busniessDaysOpenFilter - 1), day(today() - ri!busniessDaysOpenFilter - 1), ), datetime( year(today() - ri!busniessDaysOpenFilter ), month(today() - ri!busniessDaysOpenFilter ), day(today() - ri!busniessDaysOpenFilter ), ) }, applyWhen: a!isNotNullOrEmpty(ri!busniessDaysOpenFilter)
This is how I have done it now it is working properly except it is taking weekends also.
Hi Stefan, any possible solution??
Hey there is an update in the use case, If I filter by Business days=4, then this would mean that only the cases which have been open for 4 business days would come in the filter result and if the case is created on weekends then it should not take the weekend while calculating the business days for ex. If case is opened on Saturday, and the filter is applied on Tuesday, then the business days open for that case would be 2 i.e. Mon & Tue.
Mike Schmitt Is there any possible way to solve this.
Also this filter is to be done on an interface which would then populate the case details from the record.
In my applications, I store the due date, calculated at the time of writing the data. Storing a number of hours/days requires you to do that calculation at runtime. which gets you in the trouble you are.
Hi Stefan,
Any suggestions on how this could be achieved? Due date calculation is different scenario which will not wok here.We cannot store business days open field also while writing the data as well because it is a runtime function. calworkdays func works but only for displaying open days in grid column , how to apply business day search filter on top of that grid list ?
Got it Stefan but for us Due date would be today's date or the date when the filter is being applied...So is it possible to store the current data in record as a field which would keep updating itself.
This is so confusing !!! I have a hard time understanding all this logic. When I work on cases, I care about the one that is open for the longest time. Filtering for a case that is exactly open since 4 days, seems weird to me. But that is just my personal opinion.
So, can't you just not do any calculations, but adjust the filter value in a way it includes non-working time? So, on a Monday, I want to see cases that are open for more than 4 days. This means that I actually have to filter for > 6 days, right? Using a!subtractDateTime, I get exactly that date.
So I transfer the calculation from DB into the filter attribute.
This would make sense in the way I understand your explanations. But I might be completely wrong.