Archive

Archive for the ‘Project Server 2013’ Category

Timesheet Managers in Project Server 2013

July 29, 2013 2 comments

Quick Recap

One of the new features in Project Server 2013 was to do with Timesheet Managers – i.e. those that approve timesheets. In previous versions of Project Server, this was controlled via the “Accept Timesheets” permission, but the functionality has now been split out into a new section under Server Settings (PWA Settings if you haven’t added Server Settings to the Quick Launch).

 

Here’s the old 2010 group permissions:

image

And the new 2013 group permissions:

image

There are a couple of other permissions missing from the group permissions in 2013, but I won’t cover those in this post.

The Technet article about permissions for 2013 appears to be out of date (still listing the ‘Accept Timesheets’ permission), but it works as a good overview of the permissions required:

http://technet.microsoft.com/en-us/library/cc197631(v=office.15).aspx

Setting Permissions

There are two methods for timesheet approval within Project Server 2013 – fixed approval, which will turn timesheets in to the resource’s designated timesheet manager, or non-fixed approval, which allows the resource to choose the next approver for the timesheet. This method allows for the approval chains that were available in Project Server 2010.

 

To set up fixed approval routing – navigate to Server Settings > Timesheet Settings and Defaults and make sure you have checked the ‘Fixed Approval Routing’ option:

image

When submitting a timesheet with this mode on, the submission screen will look like this:

image

 

Disabling fixed approval routing will cause the timesheet submission screen to prompt for the next approver for the timesheet:

image

 

Timesheet Managers

OK, so how do people appear in the list of approvers for timesheets? Well, there’s a new menu option in Project Server 2013 under Server Settings > Timesheet Managers:

image

Simply add users to this list by clicking “Add Manager:

image

 

Setting up Multiple Approvers

If you wanted to set up an approval chain so that you have, in effect, timesheet reviewers who then forward the timesheet on for approval, this is done via permissions. Because this is a category permission, you could control which groups of users’ timesheets can be approved or not. This might be useful if you wanted only a subset of resources to review timesheets for another set of resources. This could be useful for reviewing contractor timesheets, for example.

Against the group that you want to have as timesheet reviewers, make sure that the ‘Approve Timesheets’ permission is NOT set for the relevant category. In my example below, this group could approve timesheets for all current and future resources (from the My Organization category).

image

The above settings would make this group of users able to review all timesheets in Project Server, assuming they have been selected as the approver if you have not turned on fixed approval routing.

 

Note: There does appear to be a small bug with the label when using multiple timesheet approvers at the minute. This will manifest as the following:

image

The text says <% <%$Resources:PWA,ADMIN_ADDMODIFYUSER_BROWSE%>>

Nothing to worry about, just a label bug Smile

Advertisement

Project Server Start Date Reporting Quirk

July 11, 2013 1 comment

I came across a little possible pitfall while generating some reporting for a client, which I thought I should share with the community.

 

In Microsoft Project, the Start Date in Project Information defaults to the Start Date of the first task in the plan.

image

Obviously this can be changed in the Project Information so that the Start Date of the Project does not necessarily reflect the Start of the first task in the plan, or the Project Summary task.

image

So which date does appears in the reporting database? Well, here are the results:

From the MSP_EpmProject_UserView view in the reporting database

image

As you can see, the date from the MSP_EpmProject_UserView displays whatever is set in the Project Information. This might cause some unexpected information in reports, so we need to expand our query to include the date from the Project Summary task:

image

So, when writing the specifications for your reports, make sure you’re clear which date the client wants – it’s not unheard of having a plan created a few months in advance of the work being realistically scheduled which might cause this confusion!

Obviously the clear process-driven workaround is to have your Project Managers ensure that the Start Date in Project Information is updated when scheduling the project!

%d bloggers like this: