Working on a Project Server project we discovered it’s quite easy to get issues with data integrity when users start retracting and deleting timesheets. After discussing the issue with Microsoft they gave us a workaround which solves our problem.
After a user has submitted a timesheet and the timesheet manager approves this timesheet as well the data is exported to an external system for invoicing.
The user however still is able to retract the timesheet, modify it and resubmit. It’s even possible to delete the timesheet.
Our first thought was to close the period of the submitted timesheets. But this only works partially. The user can’t modify the timesheet anymore, but is still able to retract and delete it. Not a very solid solution.
After discussing the issue with Microsoft we got this reaction:
Period close is designed to block new entries not changes which include deletions.
So this is pretty much “by design”.
Lucky enough for us the answer of Microsoft didn’t stop there:
There is a Flag field in the PSI dataset that is called
This can be set by a custom event or script when the period is closed for timesheets within the period or as originally designed, when the timesheet has been exported to a third party system for processing.
In 2007, we are looking at the data from a position where the system of record can modify the data and to help customers determine when Project Server is no longer the system of record, we are leaving it up to the customer to check that flag.
After the flag is set to true then no action can be performed on the timesheet except by duly authorized system administrators for adjustments theoretically coming from the third party system.
Indicates whether the timesheet is finalized and should not be changed.
true, the timesheet cannot be recalled, changed, or deleted.
The, important, missing peace of information is that this field is supposed to be altered by custom code instead of project server itself.