This content has been marked as final. Show 10 replies
Not sure you can do that, to be honest - the generation and display of that 'combined' person type is an internal process.
Instead, your report's driving query needs to change to include a join to the table PER_PERSON_TYPE_USAGES_F - in there, for your person_id, you will see separate rows for each person_type_id that is active as at a particular date.
I completely agree with you.
BecauseI searched a lot, there is no way possible to change the person type from front end.
Another way I am thinking now currently is to update the person_type from back end using " hr_person_api.update_us_person"
Its bit quicker way to resolve the issue rather than chaning 4-5 reports we have.
I am now executing that api and I will check all effects/side effects of it.
Lets see how it goes..
Thanks for your views.
I wish you luck, but I am not sure that will work either. Changing a person type is not necessarily the same as changing some other person attribute, such as a middle name. Person type changes tend to happen by virtue of a specific business process, eg. hire applicant, terminate employee etc - these are all distinct processes that do a whole host of other back-end stuff, and the person type change just reflects what has been done. I think you can change a person type to another of the same fundamental type (e.g. 'Emp1' to 'Emp2', where they both have a system person type of EMP) but that's about it. The whole multiple person type thing has been around for a while now, and is needed for the Trading Community Architecture, so is not likely to take kindly to being changed in the manner you are hoping to do. In any case, what happens when you've made your change, and then something else comes along and changes it to some other combination?
If it were me, I'd bite the bullet and change the reports. Thereafter, any further changes to the employee's record(s) will not affect them.
Hi agree with Clive.
Two things: In theory Applicant status should reflect actual employee status, meaning that s-he applied for a job. if then he was hired for that position - then you might want to cancel the hire then hire him her with the hire_applicant api. This might turn the employee into Employee without Applicant - but I'm not 100% sure about it.
You might try also to purge the application. this should set back the employee status to Employee. Not sure if you can purge or only end date it. if you end date it, the employee will become Employee.ex Applicant - If I understoond well it won't solve your issue.
Finally to get the person_type without Irec suffix you can use hr_person_type_usage_info.get_emp_user_person_type.
Thanks all for your responses. I will now go and change the reports.
However I have one question here. What exactly went wrong when we hired an 'Applicant'?
The Person type should have been directly changed from "Applicant" to "Employee". Why it turns into "Employee.Applicant" ??
Do we need to terminate or purge applicant record and create new employment by entering new record ??
What is the recommended practice?
Nothing has gone wrong with it, that's how it orders things. The main thing is, if you go to the person_type_usages table looking for the person type you want for your reports, how it displays that field is irrelevant. I would say the recommended practice is to leave it well alone, and let the system maintain the field as it sees fit.
If you're happy with these responses, then please mark this thread as 'answered', as it will help others to find the solution.
I raised SR with Oracle with this question and got the correct solution from them.
We can actually change the person type here from the front end by selecting the action as "Cancel Application"
If you do not see this option in the LOV then check for the following setup.
System Administrator > Profile > System > Query in your Responsibility and profile 'HR: Can%'
Is HR: Cancel Application set to YES? If not, set it.
Now my issue is resolved. I was able to change my "Employee.Appilcant" person type to "Employee" successfully.
Thanks for all your responses.
That's interesting, thanks for sharing.
I can't help but wonder, though, why you'd want to do that; in doing so you are losing sight of the fact that a given employee was an applicant at some stage. Obviously you can find that out by delving into their history etc, but to me seeing that combined person type gives you an 'at a glance' view of what happened to the employee's record. It still begs the question, what happens when some other process runs against that person record and includes a new person type in the string (e.g. he is an employee but then applies for another post in the organisation)?
I still maintain that best practice would be to incorporate the table PER_PERSON_TYPE_USAGES_F in any custom report that is looking to query based on a specific user person type.
If all your employees are hired via the Applicant process, it doesn't make sense to cancel every Application and then re-hire them as Employees.
This is more time consuming to the business users than a change to your reports to incorporate what Clive has suggested.
When the HR architecture supports it, why do you want to use a workaround ?
It is anyhow upto you and the business users :)