The CreatorCon Call for Content is officially open! Get started here.

Sporadic issue with attribute aggregete monthly (sn_plng_att_core_cpaam_effort_list) data

Jonathan F
Tera Expert

Has anybody else experienced this same situation?

 

In SPW, planning items (similar to the execution tables) generate a new project planning item on conversion from a demand to a project. Many various related tables need to be updated to point to the new project planning item, in particular I'm looking at resource assignments and the attribute aggregate monthly tables. You can spot them because - when grouping by planning item - it appears to be two unique planning items for the same task on these records. See the screenshot for an example.

 

In this example, the cpaam records in the first group were created before the demand was converted to a project, an event that occurred on Aug 4, yet the planning item continues to point to the demand planning item. The second group was created after the conversion and correctly points to the project planning item.

 

I cannot tell what triggers this situation because it seems fairly rare in our environment. In looking through the first 50 unique planning items of cpaam records (using that group by planning item), noting where the problem happens because two planning item groups with the same name appear next to each other, I spotted it only about twice. Here is what I noticed in common between the two situations that seemed anomalous (which may or may not be an indicator of root cause):

 - The broken records were created and last updated on the same day, before the conversion to a project, and yet the Task field points to that project that did not exist at the time of the creation/last updated, so the task field on the records were clearly updated without reflecting that fact in the last updated date.

 - Both planning items continue to be in a "New" "Planning state", as in they were converted to a project before being prioritized, which seems a little out of order if our fellow associates were following our SPM processes correctly

 

Another non-anomalous commonality of note: the associated Resource Assignments DO point to the project planning item table. This is important to note because if you look at the business rule that triggers on the creation of a new project planning item, the code updates the planning item field on all resource assignments and then immediately thereafter updates the planning item field on all cpaam records.

1 REPLY 1

Jonathan F
Tera Expert

I forgot to add that screenshot before posting, here it is.