There is no "Actual Finish" date field at the task level in 14.2. Does CA PPM record the actual finish date for a task, i.e., when the task is marked 100% complete? How would I capture that?
If you're in an organization that is logging time to tasks, for tasks that are not marked Fixed Duration, as ETC is zeroed out for the task assignments the Finish Date for the assignments become the date of last posted actuals. The task Finish Date then becomes the latest date of all the assignment Finish Dates. Actuals thus automagically drive the finish date - it's the actual finish date!
When the PM marks the task 100% complete, this is done as a part of a good monitoring & controlling process, but it does not necessarily equal the day the work was actually finished (our process is to update schedules every Wednesday or in weekly Project Status meetings with the teams). If 'Date Marked Complete' is important to your organization one could easily add Status to the Audit Trail on the Task Object to be able to view a Status change ad-hoc as needed. For ease of reporting one could create a 'Date Marked Complete' attribute and automatically date stamp it with the Process Engine when marked Complete.
Rob, I love your answer. A lot of organizations loosely define Actual Finish Date. We have that problem here, especially when a PM is not tracking their effort in the project and all the other effort has been completed. I love the conversation with PM's when they say the project is complete and I ask them if they are done on the project and they say no, they have some other work to do. So the definition of project complete is quite loose.
I second Rob's comments.
Additionally, I believe that stakeholders demanding to see Actual Finish are those that have history using Excel and PowerPoint for managing or reporting projects. As they start to understand scheduling tools, baselining, this need to see Actual Finish diminishes.
Another trick is to use a formula in your NSQL portlets or reports (SQL in Crystal, formula in Jaspersoft) combined with a column labeled "Actual Finish" - if Task Status = "Completed" then Actual Finish = Finish Date. OK, this isn't the date that the task was marked completed by the project manager - its still the last day that someone booked to the task as Rob explained. But this is the date that the assignees said 'Done!' and handed their work off to the next customer in the process - and, when presented to Stakeholders, they will see a label that they are comfortable with. All without adding attributes, custom processes, etc.
Worked for us and our stake holders. We then took it a step farther by using Status, Finish Date and Baseline Date to report milestones as "Completed On-Time," "Planned," "Late-Completed," "Planned Late," "Needs Baselining" and "Missing" (required milestones not appearing in WBS).
No additional attributes or processes. Left the app alone - all handled it in the portlet/reporting code.
Having the portlets/reports generate the results at run-time can save some configuration time, avoid errors when processes don't run, etc. but nothing is free - the portlets/reports may run slower vs. reading the results directly from configured attributes pre-populated by processes. We tend to prefer these solutions over configuration changes/processes - IFF (if and only if!) the portlets/reports process fast enough. If too slow, we may solve as Rob suggested, or if quite complicated, will create a materialized view (something we did for a timesheet process report that included an X-bar, moving range SPC chart).
Retrieving data ...