MPP Integration Issue with Scheduled and Actual Dates RRS feed

  • Question

  • When using an integration into MPP 2010, scheduled start and finish are populated correctly.  However, if the %age complete of a task is 100%, MPP seems to re-calculate the Actual Start and Actual Finish dates. When it does this it over-writes the existing values stored in the actual start and actual finish date fields. 

    Any ideas firstly on why this would be happening and secondly if it is possible to disable this.

    Wednesday, May 22, 2013 8:49 PM

All replies

  • StarskyJim,

    I'm not quite sure what you think Project is doing but here are the basics of how Project has always worked.

    When a plan is created, the Start and Finish (or Scheduled Start and Scheduled Finish for Project 2010 and up) represent the tentative schedule. This schedule will be dynamic depending on how closely the execution of that schedule follows the original plan. That's why a baseline should be set at the onset to preserve the original plan.

    When progress on a task is entered, there are various ways to indicate the task has started. If it indeed started as planned, the user can simply enter a value into the % Complete field. Project will then automatically set the Actual Start field to be the same as the Start field. Subsequently if the task completion is indicated by the user entering 100% into the % Complete field, Project will automatically set the Actual Finish date to be the same as the Finish field. The task was completed as originally planned.

    However, many times the task will not start exactly as planned. It may start early or late and the actual start date can then be entered into the Actual Start field. When that happens, Project will automatically adjust the Start field to agree with what actually happened. The same is true for the task finish. Given the baseline data, the variance can be tracked - original plan versus actual.

    You use the term "integration into MPP 2010". What exactly does that mean? Are you importing data into Project from some other application? If so, what and how?

    We need a little more clarification before we can adequately answer your question.


    Thursday, May 23, 2013 1:57 AM
  • John,

    Thank you for the prompt response, my understanding of the mpp principles are aligned to the explanation.

    The situation is as follows:

    I am effectively importing the data into project using an integration from 3rd party software which makes use of MPP APIs.

    The attributes being imported (not exclusively) are Scheduled Start, Scheduled Finish, %age Complete, Actual Start Date and Actual Finish Date.

    In the instance that all of the afore mentioned attributes have a value there is a problem. MPP seems to read the scheduled Start & Finish dates and then reads the %age complete value. If the %age complete value is 100%, it assumes the task was completed as planned and copies the scheduled values into the actual values irrespective of there being values in the actual fields. As a result, the actual start and finish fields are over-written with the scheduled values.

    Hope this helps explain in more detail.

    Thursday, May 23, 2013 6:32 AM
  • Hi Jim,

    I don't think it's possible to change this behaviour within project itself.

    However, if you have any control over the mapping of fields from your third party system (let's call it your ERP system) to MS Project, then you could put the ERP actual start/finish values into a pair of the custom start/finish fields. That leaves MSP to do its thing with its Actual Start/Finish Fields, and you could label the other fields as ERP Actual Start/Finish.

    However, it ultimately sounds like a defect in the third party product itself - not knowing what sort of support you've got with tha product, it may be worth raising it as a defect with them and get them to come to a solution. Particularly if remapping the fields as described above would be viewed by them as a hack which they woudln't support, it may be worth going back to them to provide a solution instead.


    Thursday, May 23, 2013 8:42 AM
  • Thanks Andrew,

    Using the Custom Dates is an option we have investigated. This does cause an issue with synchronisation back into 3rd party tool. I like the defect idea though. will try that and see if accepted as an issue to resolve.



    Thursday, May 23, 2013 1:09 PM
  • StarskyJim,

    It looks like Andrew got back to you before I saw your response but let me do a little follow-up.

    Project employs a schedule calculation engine. It takes a minimum number of data points from a user and then calculates the resulting schedule. For example, a start date and a duration are all that it needs to calculate a finish date so if a user is importing all three data points there will likely be a conflict unless the imported data matches Project's calculation algorithm exactly (i.e. dates, times, calendar, etc.).

    As I explained in my initial response, scheduled start, scheduled finish, percent complete, actual start and actual finish are all interactive, which means that not all of these data points can be imported into Project without adverse effects. If percent complete is imported then actual start and actual finish should not be. And vice versa, if actual start and actual finish are imported then percent complete should not be.

    As Andrew mentioned there are some "tricks" that can be used by importing data into extra fields, but the real question is, why use Project if you are not going to let it do what it does best, calculate schedules.


    Thursday, May 23, 2013 3:14 PM
  • In fact Actual Start can be imported, I recommend it to get the start right. I then recommend Actual Duration and Remaining Duration. Rem Dur=0 is task complete and Actual Finish date is calculated.

    If the tasks is 100% complete, then you can import Actual start and finish, but not actual duration. As advised earlier, unless all pieces of information are exactly correct, over-supplying data will cause problems.

    Rod Gill

    The one and only Project VBA Book

    Rod Gill Project Management

    Wednesday, May 29, 2013 8:35 PM