The new Aggregated Calculated Attribute (ACA) functionality has been introduced on 14.3, it is a powerful tool with generic logic built for all objects. With this functionality we can now do things like displaying Actuals on a stock or custom Project List page that is updated dynamically, whereas in previous versions we would configure the stock Actuals attribute on project list and rely on the Investment Allocation job to keep it updated.
Since the logic behind ACA is generic, when creating an ACA for an object we need to consider behaviors specific to the object and the subobject that we use. In the example of displaying task Actuals on a Project List, how Actuals is displayed on a task hierarchy will affect how an ACA should be built.
In a task hierarchy where we have summary tasks (cannot have assignment) and detail tasks (can have assignment), information such as Actuals are displayed in a roll-up manner for the summary tasks, therefore when building a project ACA using task Actuals we need to exclude summary tasks so that the information is aggregated only from detail tasks.
Shown below is a task hierarchy where the detail task 'Preliminary Market Assessment' is the only task in this project that has Actuals, when viewed on the PPM Gantt we see that Actuals is also displayed for its parent task 'Preliminary Business Case' and grandparent task 'Business and Market Assessment'. The whole project in fact has only 56 actuals, and this display is as expected based on the design of how task hierarchy works.
If we create a project ACA for task actuals using an expression AGG_Sum(task.practsum) without any filter, the ACA displays 56x3 = 168 which is incorrect as it also count all tasks above the detail task on its hierarchy.
If we provide a filter on the ACA, such as one shown below:
The actuals are now aggregated only from detail tasks. In this example it will display 56 on the project list page.