Prevent or control status changes in CPRO structure objects

[Former Member]

Hi all:

I think I've seen this done before in a previous example/ implementation, but how does one prevent or control automatic status changes from occurring in cProjects, as in the standard system?

Business need/purpose:

1.  To prevent the mass REL of tasks to project participants for execution  (i.e. WF event notification)

2.  To effectively track and manage which project activities are truly "Ready for Processing", without having to analyze project structure dependencies and relationships

Business scenarios:

1.  Item/Project from CRTD to REL (i.e. by project coordinator), but automatic Phase REL needs to be prevented  (discretion of PM or PMO Ctrl)

2.  Phase from CRTD to REL, but automatic Task REL for entire subtree needs to be prevented

• As with #1 above, direct child objects are released along with parents.  This means the task tree under Phase 1 all gets released.
• In reality, not all L1 tasks for a Phase becomes ready for processing once the phase is released.
• Consider task dependencies and relationships:  Certain successor tasks don't need to be released until parents are completed.
• In reality, only tasks without successors (other tasks) within the phase (or tasks outside the phase that are not completed CMPT) should be released.

3.  Parent Summary Task from CRTD to REL, and automatic Child Task REL of entire subtree needs to be prevented

• As with #2 above, direct child objects are released along with parents.  This means the task tree under the parent summary task all gets released.
• Same argument as with #2's bullet points above, there needs to be some kind of control over which subtasks get released, based on dependencies and relationships.

4.  Finally, once predecessor tasks are CMPT or CNCL, then successor tasks should be automatically REL, but only if no other predecessors exist that are not CMPT or CNCL.

At the very least (or, solution question 1 of 2) I'd like to understand if there's a way to disable the standard automatic release of entire sub-objects/ sub-trees when parents are released.  The next step (or, solution question 2 of 2) would be to enable "controlled" automation using a combination of relationships and status should happen from the phase-down.

Any thoughts?  The only way I can think to do this is via custom development and workflow using BAdI DPR_EVENTS and the various BAPI_BUS function modules.  I'm wondering if anyone's come up with any other options, especially if it's close to standard, or uses standard to a great degree, before resorting to custom code.

Thanks much!

Lawrence

[Former Member]

As a follow-on, I just realized another benefit / business purpose for enabling this:  cleanup, to fix those "just in case" moments when Phases, etc. are accidentally released.

Take for instance if Phases are progressed accidentally  (if no approvals are required by config of course).  There may be circumstances where DPs would need to be rolled back for the purpose of "accuracy" in management reporting.  This, despite the condition that entire phase sub-objects in CPRO are now released.  I would imagine that intentionally not configuring DFM sync for any other status than REL would not be a very clean solution.

I realize there are pros and cons to both, but if controlled release of tasks were available, then there would be less concern about breaking sync and data inconsistencies.  Furthermore, I propose that the authorization to begin Phase work would be the accountability of only a few people by proper role authorization, i.e. the PMO or Project Managers.