J
Jason Elios
App Name: Microsoft Project Server 2003
We have an external process that populates the MSP_TIMEPHASED_DATA
table with actual work for project plans on a weekly basis. We use the
"EXT_EDITED" flags as suggested by Microsoft.
I have confirmed that what we want to push into the TIMEPHASED_DATE
table and what makes its way into it are in sync.
The following is an example of the behavior we are noticing.
I have verified that the timephased_data table contains actuals of:
1000hours for Resource A assigned to Task 1
2000 hours for Resource B assigned to Task 1
0 hours for Resource C assigned to Task 1 (this is indicated by NO rows
for this specific Resource and task existing in the table).
The task is set to Fixed Duration and has a Start Date of Sept 1 2005
and a Finish date of Dec 31st 2005.
When the file is opened I will notice something like this:
Resource A has a total of 1200 hours of Actual Work.
Resource B has a total of 2100 hours of Actual Work.
Resource C has a total of 900 hours of Actual Work.
In addition, assume the last date actuals have been entered in is the
last week of November of 2005. I will notice that end dates being
extended out a couple of months and work being spread across that time.
The problem is two fold. Additional actuals have been manufactured and
Finish dates have changed when they should not have.
If I close the file without saving (so that I don't overwrite the
timephased_Data table data) and change the task to fixed work or fixed
units by modifying the task_type field in the MSP_Tasks table, I notice
the correct actuals when I open the file again. The dates have off
course re adjusted but the total actuals and the individual values in
the weeks are correct to the decimal point.
I have also tried to manually replicate the issue by creating a fixed
duration and entering all the data manually (work and actual work) in
the timephased buckets. In this case I noticed the correct behavior
where the finish date remains constand and the remaining work is
re-spread accordingly.
Can anyone explain this weird behavior?
Thank you,
Jason Elios
We have an external process that populates the MSP_TIMEPHASED_DATA
table with actual work for project plans on a weekly basis. We use the
"EXT_EDITED" flags as suggested by Microsoft.
I have confirmed that what we want to push into the TIMEPHASED_DATE
table and what makes its way into it are in sync.
The following is an example of the behavior we are noticing.
I have verified that the timephased_data table contains actuals of:
1000hours for Resource A assigned to Task 1
2000 hours for Resource B assigned to Task 1
0 hours for Resource C assigned to Task 1 (this is indicated by NO rows
for this specific Resource and task existing in the table).
The task is set to Fixed Duration and has a Start Date of Sept 1 2005
and a Finish date of Dec 31st 2005.
When the file is opened I will notice something like this:
Resource A has a total of 1200 hours of Actual Work.
Resource B has a total of 2100 hours of Actual Work.
Resource C has a total of 900 hours of Actual Work.
In addition, assume the last date actuals have been entered in is the
last week of November of 2005. I will notice that end dates being
extended out a couple of months and work being spread across that time.
The problem is two fold. Additional actuals have been manufactured and
Finish dates have changed when they should not have.
If I close the file without saving (so that I don't overwrite the
timephased_Data table data) and change the task to fixed work or fixed
units by modifying the task_type field in the MSP_Tasks table, I notice
the correct actuals when I open the file again. The dates have off
course re adjusted but the total actuals and the individual values in
the weeks are correct to the decimal point.
I have also tried to manually replicate the issue by creating a fixed
duration and entering all the data manually (work and actual work) in
the timephased buckets. In this case I noticed the correct behavior
where the finish date remains constand and the remaining work is
re-spread accordingly.
Can anyone explain this weird behavior?
Thank you,
Jason Elios