cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Prevent or control status changes in CPRO structure objects

Former Member
0 Kudos
1,240

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 releasedThe 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

View Entire Topic
Former Member

Hey Lawrence,

I had a very similar requirement one of my projects sometime ago. My initial thought was also to change the standard behavior and control the task status. However, due to the technical complexity and other potential issues we decided to use workflow instead.

To elaborate further, instead of controlling the task status, we decided to control when the email notification was sent to the folks who will be doing the task. We also used the Process field (you can use any other field or custom field for this) to capture if a task is "Ready for Processing" or "Not Ready for Processing".

When a phase is released, all tasks will be released as in standard, however the email notification will only be sent for tasks which do not have predecessors and process will be set to "Ready for Processing". When a task is completed, the workflow will check if there are any successor tasks and send the email notification and process will be set to "Ready for Processing". We had to build in conditions to figure out what to if new tasks are created, relationships changed, multiple successor predecessor tasks etc, but you get the general idea. The reason we set a value in the process field is so that the task dashboard can be filtered to only show tasks which are "ready for processing".

With this approach we were not messing around with the task status, it still eliminated the need for any manual release and the development was less complex.

Hope that helps and best wishes for 2014.

Lashan