Modifying project through XML appears to calculate incorrectly.

[bcoleman]

I am using VB code to modify a project which has been saved as XML. The only
modification I'm making is to add actual work to the project which I do by
modifying the TimephasedData nodes in the xml document for the associated
assignments. Specifically I open the XML document, delete the existing all
timephased nodes for the assignment, and then create new timephased node for
the actual work. The reason I do this is because I’m potentially adding many
timephased data entries and have found in the past that it’s very slow when
doing this through the API However, this does not seem to calculate
correctly. An example of this:

1) Create a project with one fixed work task with 6 days duration and 42
hours planned work. The units on the assignment are calculated at 88%. If
you examine the task through the Task Usage view you see an even distribution
of 7 hours per day. Save this project as an XML file.

2) Open the project in the WinProj client from the XML file. Through the
Task Useage view add 10 actual hours of actual work on the first day of the
task and 1 hour on the second day. At this point the task duration has
changed to 6.43 days and my remaining hours are distributed over the next 5
days as follows: 7,7,7,3. As well the units have been recalculated to 125%.
Close the file without saving.

3) Modify the XML document to add to TimephasedData nodes for actual hours:
10 hours on the first day and 1 hour on the second day. Open the file in the
Winproj client and you'll see the following remaining hours: 7.03, 7.03,
7.03, 7.03, 2.83

Can anyone explain what I'm doing wrong to get this discrepancy?

 

[Brian Pieslak]

bcoleman,
My team and I are encountering the exact same issue. Have you tried
setting the calculations to manual?
Its under Tools > Options > Calculations tab - set the Calculation Mode
Radio button to Manual.
Then try opening your XML file. With the Calculation Mode set to
Manual, we have found that the XML is read correctly by Project Professional
upon opening the file. However, once we tell Project Professional to
perform its calculations, our Task Duration changes from 6 days to 6.02
days, and our Task Work changes from 40 hours to 40.17 hours.
Its not a final solution, since most people their calculation mode set
to Auto, but it at least gives you better insight into how accurate your XML
is.

One thing to be aware of with setting actual time for a task in Project
XML:
I believe that you need to set more than just the TimephasedData.
In both the Task and the Assignment tagsets, there are ActualStart,
Stop, Resume, and PercentComplete fields, which we've found to definitely be
used in Project's calculations. I am not 100% certain *how* these values
are used by Project, but we have found that we must provide accurate values
for these tags in order to get Project's calculations close to what we
expect.

Please let us know if you are able to work past your issue, and we will
do the same.
Good Luck!
Brian

 

[bcoleman]

Brian,
thanks for the information. I agree with your observations about
the additional fields as well. I have noticed that in my example there
appears to be a small difference in the Finish value when I add the modify
the plan through XML vs when I make the change in the WinProj client In both
cases the date portion is the same and correct, but the time portion of the
Finish at the task level is different by a little bit less than 20 minutes.
If I adjust the time portion of the Finish value at the Task level in the XML
document then I get the distribution I would expect. The only problem is I'm
not entirely sure how this value is calculated. Anyway, I'll try applying
your suggestion today and see if that helps. Either way I'll update the
discussion with the result (or if we have any sort of breakthrough). Thanks
again,

Brett

 

[Brian Pieslak]

That's exactly what we've found, as well.
Our PTM values are just *slightly* off, which unfortunately produces an
unusable result for us.
Someone on our team is continuing to look into that PTM calculation.
We'll be sure to post what we find.

Brian