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).
Dale