Following on from my previous post on Project Server timesheet line status and project plan and assignment deletions, this blog covers another scenario that can catch you out – the relationship between the assignments and the timesheet with regards to status updates, and the idea that this was worth blogging about came from reading the comments in that previous post – and the thread in the forum referred to in the comment where Treb and Elli had discussed the ramification of this issue. I had explained it in the thread – but will post here to hopefully reach a wider audience.
Imagine you have 4 timesheets, and one assignment that happens to span all of them. The first week – and lets call this one w/c 2/17/2014 – has been submitted and approved. The timesheet line status is 1, and for all other timesheets the line status is 0. We have a handy table in the reporting (dbo) schema called MSP_TimesheetLineStatus and this shows us that one line is Approved, and all the remainder are Pending. So far so good.
Now I have entered time in the next 3 timesheets – and some of these happen to be in the future – so not always a good thing to get ahead of yourself – but this could equally happen if they were in the past. The key issue is having multiple timesheets in progress at the same time – but I appreciate it isn’t always easy to keep this from happening. To visualize this better here is a representation of where I stand – with Timesheet 1 approved and time entered in the other 3 as follows:
Next I go to Timesheet 2 and submit status. Once I do this then I see that each of my three timesheets says Awaiting approval against my assignment.
As an example, here is a screenshot of Timesheet 3 – for w/c 3/10
But I didn’t click send anything on this timesheet? Taking a look directly in the database we can see what is going on. The line with the comment and the status of 1 is our approved timesheet 1 – and the status of 4 (pending approval) is for timesheet 1. But why do the other 2 say 0 (Pending) and not 4?
This is a little like the issue of the deleted tasks in the previous posting – if I go to Timesheet 3 for example, and add a vacation and just save – I then see this…
I have an extra row of course, but my previous line with 0 is now showing a 4. So once I opened my timesheet I can see awaiting approval, but only when I save (and I need to make a change such as adding a line or changing time) does this get persisted back to the database.
This scenario is often commented on in the approval center where it is more obvious that time from multiple timesheet periods is being presented. And if I scrolled right I would see more red 7’s.
And if I now approve? Hmm – I now see I have 3 approved lines from timesheets 1 to 3 – and my vacation on timesheet 3, but still don’t see approval of the 4th.
Even though this ‘said’ awaiting approval on the timesheet, as I hadn’t saved it, it was really still in the Pending status (as seen in the DB) – and if I look in the timesheet now it says Not Submitted, as no part of this assignment is actually in the awaiting approval status.
So the question that started all this was how do I check to see what has been submitted even if it isn’t approved – and without using timesheets per se – and overcoming the scenarios above. One thought I had was to use planned work – assuming that was somewhat accurate – then do a left join to see if there is matching submissions. In the forum thread Elli had another approach – and I can’t think of a better way – that uses the fact that a comment is present as indicative of submitted time. I’d be interested on any other workarounds or issues people are experiencing with this behavior. This was 2013 – but same for 2010 and Project Online.
Does this affect Timesheets in closed periods as well?- Tom at TASB
This finding has been affecting our organization quite a bit as we've moved into production Jan 1 with 2013 and are dealing with a lot of growing pains. Related to another bug we've reported regarding custom line classifications, we have had to recall, correct, and resubmit many timesheets. If the approver accepts the task update from the prior period, then they are accepting all time against that task for all periods whether the line has been submitted on a timesheet or not. I figured that maybe we could possibly use the "Set Date Range" filter to limit the scope of what was being approved, but it doesn't work in that manner. I have also learned that if you made an adjustment to a timesheet period that is not within the approvers "Set Date Range" range, then the "Scroll To Update" function will not actually take you to the update. I'm curious, because I don't see mention in your posting about this, do you see this as a bug that will be addressed or are you only informing the readers?- Nate
I don't see this as a bug Nate - it is the way it was designed. I am just making readers aware of the design, as talking to people it wasn't widely known or understood. It comes down to two separate things - time recording and statusing - if you want them to be totally apart then just enter time in your timesheet - don't use single entry mode - then import timesheets into my tasks when you wish to update the time into your plan. Single Entry mode does make things 'easier' - but nothing comes fro free and I just wanted to be sure people were aware of the full nature of the integration. Hope this makes sense Nate. As an aside, if someone has entered status for an assignment that doesn't happen to be in the current timesheet period - why wouldn't I - as a Project Manager - want to know about it. As a person monitoring timesheet compliance I can see that it opens another can of worms. The thread from Elli and Treb that I reference gives some great scripts to deal with this aspect.Thanks for the feedback - it is difficult sometimes to get features that work the way everyone wants. But at least understanding how they work can allow you to work in the best way that suits you.Best regards,Brian.
And Tom, this doesn't affect the timesheets at all - it just affects the statusing - so if the timesheet is closed the statusing for that part of the assignment would already have happened.And back to Nate's point - there is in fact a bug that does affect the line status - but the main point of the article and the assignments outside the current timesheet being submitted is by design.Best regards,Brian
Thanks Brian for the response. With respect, I would question if the system is acting as designed with regard to the status updates reflecting all time on all timesheets when using SEM, or maybe I'm questioning the design in part. My reasoning is twofold.First, when I send an update by turning in my final timesheet, then the status update logic will include all time on all timesheets including those that are only saved. While I agree with you that a PM would want to know about valid time, it's a leap for them to want to accept time that has only been saved and never sent as an update, as this may only be a draft entry.The second part is the descriptors in the application. The "Send Progress for All Tasks" option description reads "Update the project plan with the hours you've entered for this period." That's pretty clear that you're only sending the hours for this period, not all periods. I have to admit, I have not tested this scenario exactly because my dev system is out of order today. My standard testing involves only turning in the final timesheet. Does the send progress option work differently in sending the update than the "Turn in Final Timesheet" option? Even if it does, in the end the user will turn in the final and that action will send updates for all new time in the system regardless of period. I think the wording used on the send update option conflicts with the idea that this was the design. When I get the chance, I will do some more testing to better educate myself on this particular feature.Regards,Nate