Time Sheet Portal - hours in the Time Sheet Section

mah1
Kilo Sage

Vancouver Patch 8

 

How are the daily hours in the Time Sheet section of the time card portal calculated? What is included here? It doesn't appear that this always matches what is shown in the time sheet breakdown section or in the the logged time cards section.

 

For example, we have a user who submitted a time sheet with 40 hrs for last week but the info in the time sheet section shows less than 40 hrs. The time sheet breakdown show only 27 hours but the total for project tasks (33.5) and catalog tasks (6.5) is 40.

 

The documentation indicates that this displays the total number of tasks and hours entered for each day in the week. The total number of tasks is correct but the hours are not. The missing 13 hours on this time sheet were all logged to a project task where the user is an additional assignee.

 

See below:

 

timesheet.png

 

Thank you

1 ACCEPTED SOLUTION

Ok, we can rule the domain separation out. Thank you for confirming the values. 

Time cards are associated with a time sheet with this business rule:
[your instance].service-now.com/sys_script.do?sys_id=1a6e3e409350220064f572edb67ffbf0
"Associate time card to time sheet"

This part seems to work fine, it is not responsible of updating the values on time sheet, we don't need to investigate it.

 

The after insert/delete (order 300) BR which updates time sheet when time card is inserted or deleted:
[your instance].service-now.com/sys_script.do?sys_id=d7edc54347031200b3207eaecb9a71a5 

"Rollup hours fields on Create/Delete" 


And the BR that updates time sheet on update (after update, order 300): 
[your instance].service-now.com/sys_script.do?sys_id=ba7d8fd747031200b3207eaecb9a7125

"Rollup hours fields on update"

 

These BRs are failing in some scenarios. Please confirm the following:

  1. business rules exist and are active
  2. Business rules are OOB
  3. If 1 and 2 are passed, check for any custom business rules in table time_card. Search script field for "current.setWorkflow" to find if any of them is causing the BRs down the line to not trigger

 

For example, if there's a business rule that triggers after update, order 200 and the script contains row "current.setWorkflow(false);" this would prevent the after business rules of order >200 from triggering. 

View solution in original post

8 REPLIES 8

the business rules exist and are active

as far as i can tell, they are OOB

i did find a custom business rule on the time_card table  (Correct Category for Projects)

it is a before insert/update order 10

conditions: task starts with PRJ and category is not Project/Project task

with the following script under advanced:

(function executeRule(current, previous /*null when async*/) {
current.category = 'project_work';
current.setWorkflow(false);
})(current, previous);

i commented out the current.setWorkflow(false) line and added a time card from the time card tab of the project task...  the daily totals were updated as expected...

 

i need to research why that business rule was set up that way...

 

thank you

Since the custom BR is responsible for setting the category and prevents further updates, it is likely that there is another rule that modifies the category after the [before insert order 10]. I couldn't find any such logic OOB, but this is a bit more difficult since most of OOB logic is in the script includes global.TimeCardGenerator and global.TimeCardUtil , so it's always possible I missed something (even if I searched all the BRs that use them).

It's also always possible that the current.setWorkflow(false) was just added there when someone just copied code without understanding what each row does. 

Thanks for marking my earlier response as helpful. If you think that it solved your initial question, consider also marking as the correct solution so that the future readers can easily find the question and solution. I hope you find the reason for the custom BR, good luck in your research!

it appears that when you create a time card from outside of the time sheet portal (like from an incident or a project or a project task...), the category is defaulted to task. it appears that they created this business rule to set the category to project/project task when the task starts with prj.  that business rule was created 8 years ago by a consultant that helped with the initial implementation of servicenow. so not sure i'll be able to figure out why they did that but plans are to remove the cancel workflow and test to see if that breaks anything.

 

thank you so much!