Share via

Report Pack Setup

  • Article

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The report pack for Microsoft Office Project Server 2007 includes seven sample reports created with Business Intelligence Development Studio for Microsoft SQL Server Reporting Services (SSRS) 2005. Installing the reports requires changing the data source and report server parameters in the report project. Several reports require additional custom fields and a new lookup table, along with specific kinds of data.

The Project 2007 SDK download includes the Project Server report pack. For a link to the download, see Welcome to the Microsoft Office Project 2007 SDK.

Configuring the Reports

The reports are all contained in one business intelligence project named Project 2007 Report Pack. The project is configured to use a server named PS2007DEMO, with the Reporting database (RDB) named Project2007DemoDB_Reporting. To use the report pack with your server and database, you must edit the server name, the RDB name, and the target reporting server URL. When you change the parameters in the project, all reports in the project are published to the specified report server.

To configure the reports:

  1. Copy the files in the Code Samples\Report Pack subdirectory of the Project 2007 SDK to a directory on a computer where you have the Microsoft SQL Server Business Intelligence Development Studio installed.

  2. Open the Project 2007 Report Pack.sln file. If Microsoft Visual Studio 2005 is installed on the same computer, the report project opens in Visual Studio.

  3. In Solution Explorer, double-click Project Data Source.rds. In the Shared Data Source dialog box, click Edit.

  4. In the Connection Properties dialog box, modify the server name, the RDB name, and the authentication fields if necessary.

  5. Click Test Connection to make sure the connection works, and then click OK. Click OK again to save the data source information.

  6. On the Project menu, click Project 2007 Report Pack Properties.

    1. Change the TargetServerURL value to the URL of your report server. The value for the sample project is http://ps2007demo:81/reportserver.

    2. Change the TargetDataSourceFolder value if necessary. The value for the sample project is Data Sources.

  7. Build and then deploy the solution to your SQL Server Reporting Services instance. On the Build menu, click Deploy Solution.

Figure 1 shows SQL Server Management Studio after you deploy the Project 2007 Report Pack. For the reports to work correctly, you must add the necessary custom fields and lookup table.

Figure 1. Project 2007 Report Pack deployed to SQL Server Reporting Services

Project 2007 Report Pack deployed to SSRS

Creating the Lookup Table and Custom Fields

Several of the reports use custom fields that are based on the Health Trends lookup table. Values in the Health Trends lookup table specify project status as of a specified reporting period. The Health Trends structure is [Reporting Period Date].[Status Color], where dates in the sample reports are Fridays of the weekly reporting periods.

The reporting period reflects a normal update cycle for your organization and can be changed to represent weekly, monthly or quarterly updates. The reporting period values form the x-axis of a cross-tab report. Figure 2 shows part of the Health Trends lookup table definition in Project Web Access for a weekly reporting period.

Figure 2. Health Trends lookup table definition in Project Web Access

Health Trends lookup table definition

The reporting periods must include the dates you need for reports of your project data. For information about programmatically creating a lookup table, see Walkthrough: Creating a Hierarchical Lookup Table.

The reports need two custom fields that use the Health Trends lookup table. The following table shows the custom field names and properties. Figure 3 shows the Cost Health Trend custom field definition in Project Web Access.

Custom Field Name

Properties

Cost Health Trend

  • Select the Health Trends lookup table.

  • Select Only allow codes with no subordinate values.

  • Multivalue enabled. Select Allow multiple values to be selected from lookup table.

Schedule Health Trend

  • Select the Health Trends lookup table.

  • Select Only allow codes with no subordinate values.

  • Multivalue enabled. Select Allow multiple values to be selected from lookup table.

Figure 3. Cost Health Trend custom field definition in Project Web Access

Creating Cost Health Trend custom field

Note

Project Server creates the MSPCFPRJ_Cost Health Trend_AssociationView and MSPCFPRJ_Schedule Health Trend_AssociationView views in the RDB after you create the multivalue custom fields. If you create the custom fields but the views do not exist, check whether the custom fields are multivalue enabled.

NoteNote

Project Server creates the MSPCFPRJ_Cost Health Trend_AssociationView and MSPCFPRJ_Schedule Health Trend_AssociationView views in the RDB after you create the multivalue custom fields. If you create the custom fields but the views do not exist, check whether the custom fields are multivalue enabled.

Data Required for the Reports

Most of the reports require specific data to work properly. Following are some examples of required data:

  • The Cost Center Availability report uses the Cost Center field for all resources.

  • The Project Give and Get report requires some projects that have deliverables that are linked to a task.

  • The Project Portfolio Trend report requires the Schedule Health Trend and Cost Health Trend project custom fields. The report manager selects a subordinate value in the project as each reporting period is reached.

  • The timesheet reports require defined timesheet periods.

  • A meaningful timesheet period prefix, such as FY06-, should be provided to make the timesheet reports more relevant.

  • At least one timesheet should be submitted for the timesheet reports.

  • A designated timesheet manager who is someone other than the resource should be provided for some of the resources.

  • For the Work versus Effort Audit report, timesheet data should be entered at the task level.

NoteNote

Reports with a Sub prefix, for example SubReport - Resource Assignment Details, are designed to be executed from another report, not executed directly.

See Also

Tasks

Walkthrough: Creating a Hierarchical Lookup Table

Concepts

Cost Center Availability Report

Project Deliverable Gives/Gets Report

Project Portfolio Trend Report

Project Proposals Listing Report

Project Review Report

Timesheet Audit Report

Work Versus Effort Audit Report