LaborUnits and NonLaborUnits reading from P6 is inconsistent
JanecekPetr opened this issue · comments
The current implementation of getPlannedWork() for P6 XML files sums plannedLaborUnits and plannedNonLaborUnits.
The current implementation of getPlannedWork() for P6 XER files just fetches plannedLaborUnits (target_work_qty column). There's no way to get plannedNonLaborUnits (target_equip_qty column).
This inconsistency made us abandon a feature completely for now as confusing numbers are worse than no numbers at all :(.
The possibilities to unify the behavior are numerous, but the simplest approach for now without introducing any new fields would be to make XML files provide just plannedLaborUnits, just like the XER files do.
The non-labor units fields can come separately if that's something you'd consider.
As a workaround we tried calculating both fields using the assigned resources. However, this breaks when there are no resources of the relevant type. P6, when you remove the assigned resources, asks whether it should zero-out the relevant planned*Units field or keep it. The calculation then simply returned 0 even though the original file definitely had planned*LaborUnits set.
I simplified the description and put emphasis on the actual inconsistency which is the heart of the problem.
We're happy to provide a fix, but it's unclear whether you'd like to just go the simplest path for now (make XML files read plannedLaborUnits only), the other way (make XER files sum plannedLaborUnits and plannedNonLaborUnits), or a different route completely (provide new fields?). We're currently only interested in LaborUnits, but who knows what the future holds...
Do you prefer any particular way to achieve consistency and/or providing the relevant field values?
The text only mentions the planned variant of *LaborUnits, but obviously all variants need to be consistent.
Thanks for the updates, I will take a look at this over the next few days.
Hi @JanecekPetr,
This inconsistency made us abandon a feature completely for now as confusing numbers are worse than no numbers at all :(.
Sorry about that, I hope that MPXJ is normally a net positive rather than a hinderance!
To rectify the issue you've raised I have updated MPXJ to ensure that both the PMXML and XER/database reading code sum the labor and nonlabor amounts when populating the Work, Actual Work, Remaining Work and Planned Work attributes., so they are consistent.
Alongside this I have also provided new attributes on the Task class to allow you to access PlannedWorkLabor, PlannedWorkNonlabor, ActualWorkLabor, ActualWorkNonlabor, RemainingWorkLabor and RemainingWorkNonlabor as individual attributes. MPXJ will read and write these for all P6 schedules. (I've tried to keep the naming consistent with what MPXJ already has rather than using P6's terminology directly).
Probably not relevant for you, but there is a heuristic in place when writing schedules to XER or PMXML which deals with work values from non-P6 sources which don't have a labor/nonlabor breakdown. At the moment the code assumes in this situation that all work is labor and populates the attributes appropriately to reflect this.
The changes have been merged, and I anticipate a new MPXJ release being available in the next few days.
This is great. Thank you very much.
I hope that MPXJ is normally a net positive rather than a hinderance!
Oh you bet. If we ever meet in person, a beverage of your choice is on me!
there is a heuristic in place when writing schedules to XER or PMXML which deals with work values from non-P6 sources
As a matter of fact, this just became relevant, too. Thank you for the thought, it is indeed useful.