Clarity

Good Day, 

This is a question and maybe even a discussion item.  I am working on a data pull, and may revisit reports, concerning people who were employees, left the organization, then return as contractors who must record time.  We currently identify employees/contractors as a person_type (on srm_resources).  We then report hours for projects based on this person type (Employee/Contractor).

Our question is, how do we identify someone as both, not simultaneously, but with independent start and term dates and person type.  When we look at the interface for resources we see single entries which do not appear to differentiate a member based on a particular type with independent dates as a type.  

We have tried this with a resource in our DEV environment.  It just overrides the previous data entries.  The issue for the reports/datasets that I am writing is cumulative and will cause data variants.  Consider the following,

• Example:  I have an employee where we track capitalization of hours for projects (not global).  We report out these hours on a monthly basis and the report accurately accounts for capitalization of employee hours and contractor hours separately.  Over time we have employees who leave and become contractors and vice versa (that is, contractors who become employees).  Now our stakeholders would like to do an audit review of the data.  As a result they ask us to go back in time and come forward with a full data set.  Because we have made changes to employees/contractors the numbers no longer add up as they did previously (due to the changes in employee/contractors).

As you can see in the example, this could cause the report to come into question, this is despite that the hours are not incorrect.  Rather, they are being globally bucketed differently because or person-type has changed with no date discrimination.  

Back to my question, is there a way to keep the person, but also annotate the type by date so that data will remain accurate over time?

Thank you

Michael

One might think that reporting from Transactions (say PPA_WIP) ought to cover this, as a transaction records many things about a project and resource as of the posting date.  However, Employee Type is not one of these items, unfortunately.

Option 1:

Simplest solution, staying all out of the box, might be to utilize different transaction classes for Employees and Contractors.  This might be redundant with Employee type, but at least Transaction Class is one of the items recorded in a transaction at posting.  Or, use Resource Class (e.g. instead of just Labor, use "Labor-E" and "Labor-C").  Again, this is one of the items recorded at posting.

Then, update reports to pull this content from the transaction records, rather than from the Resource object or some custom solution.

To avoid errors (e.g. Employee Type set to "Employee" and Resource/Transaction Class set to "Labor-C"), one might consider having a process/job set the Resource/Transaction Class of the user based on their Employee type - remove the human update/error potential.

Option 2:

Close the original resource/user account and open a new account with the resource's new Employee Type.

This might be the simplest solution from a data standpoint, but if contractor gets hired without leaving, it makes for a lot of admin work to reallocate projects, tasks and anything else owned by/assigned to the resource.  Ugh!

Option 3:

Custom reports.  Turn on Audit Trail for Employee Type (Person Type) and have reports find audit results corresponding to dates used in report.  If nothing in Audit Trail, then read from Resource Object.

Option 4: 

CA adds Employee Type as one of the attributes recorded with transaction at its posting.  (And, while at it, includes it as factor when calculating cost plans from allocations/assignments!)

Best Option:

• Option 3
  • Best:as there is nothing to do except turn on an out of the box feature and then report from this 'out of the box' data source.
  • And, one can do this now

Note:  Option 4 should be the best solution, but one may wait years for it.

Hope this is helpful, and looking forward to anyone with something creative that I've missed.  I tried to stay 'out of the box' as much as possible, so avoided any custom solutions in this reply.  We use a mixture of Options 2 and 3, only because some have the impression that they must close an account and open a new one - but this is done out of misunderstanding and/or local BU business rules, not CA PPM dictate.

Dale

Thank you Dale.  That information if very helpful.  I believe we will try to go with Option 3; fortunately we have not created semi-duplicate member accounts--one for each person_type.

Michael.