Timesheet Questions

[AlexOnTheHill]

Hello,

 

I have users looking to implement Timesheets and I have received a request from management for clarification regarding the permanence of the entries recorded.

There is a concern that once the entry is created it could be amended by the user or a colleague after it is reviewed by management at the end of the week/month.

 

I understand that there is an audit history so we could see what changes are made any by whom but do we have a way to lock completed entries?

I have looked for clarification in the wiki but cannot see an answer, I also cannot see whether someone in the same team with the Timesheet Manager User role is able to edit a colleague's entry.

 

I would also like to know if there is a limit on the number of categories that can be created.

 

Many thanks in advance, timesheets are a subject that did not come up during our onboarding and now there is interest in using the feature management are looking for some reassurance regarding the robustness of any figures they may use coming from them.

[AlexOnTheHill]

Just checking in, any advice would be appreciated

[AlexTumber]

@AlexOnTheHill thanks for your post.

Once a timesheet value/entry has been created, it can be amended by it's owner, or any user that has visibility of the owner's timesheet. This is controlled by the visibility area in the admin section.

As you say there is a full audit history that is read only which captures any changes to the individual timesheet value/entry.

There is no current way to 'lock' completed entries, however we've had a change in our backlog for a long time to introduce the concept of timesheet approvals. This is particularly important in project management for example.

There is no limit on the number of categories that can be created.

Happy to answer any further questions you have.

Alex

[AlexOnTheHill]

Thank you Alex, I do have a further question about timesheets and that is around reporting:

The in built reports do not allow the manager to get a list of calls associated to a particular category, for example. Calls can only be viewed if they select a daily view.

How can a manager report on which requests have used which categories over a longer period?

I have looked at creating a report but timesheet IDs are not mentioned in requests and request IDs are not mentioned in timesheets, is there another table I can use to bridge the two?

[AlexOnTheHill]

Good afternoon,

Just checking in, would it be possible to take a look at the above regarding the reports?

[AlexOnTheHill]

Good morning,

Checking in, would you be able to offer some advice regarding the reports?

[AlexTumber]

@AlexOnTheHill  reporting on which requests have used which categories over a longer period is something that can be done with a custom report. Unfortunately we don't offer this by default but there is no reason why we couldn't add this functionality in the future.

The data in the table h_timesheet_values can be joined with requests by using the h_related_urn column.  Typically you'll see a value of something like this: urn:sys:entity:com.hornbill.servicemanager:Requests:IN00000207

Alex

[AlexOnTheHill]

Thank you for your help with this one. I've had a go creating a timesheet report however I don't seem to be able to extract useful/user friendly information from it.

Here, I don't seem to be able to get timesheet IDs, Request IDs or Sub-categories (attached)

It makes sense that not all timesheet entries have a Request ID because someone may allocate time to do a number of requests and put in an entry that says 'admin time'

The amount of blanks though makes me wonder if I have joined the tables incorrectly.

ict---timesheet-test-report.report.txt

[AlexOnTheHill]

Good morning,

Just following up on the above, does the report look correct?

[AlexOnTheHill]

Just checking in, could someone take a look at the report and suggest how it could be reconfigured to capture the details we are looking for?

[AlexOnTheHill]

I have been able to solve the issue with the report, the tables just needed a join on both the category ID or the subcategory ID against the name field.

This does produce two results per request but that's better than having to work out what the subcategory ID was referring to.