Hello ..

The data here is interesting .. It would seem the USAGES_F data is correct ..

However the PEOPLE_F.person_type_id (as i understand) should hold the PER_PERSON_TYPES.person_type_id for the associated default SYSTEM_PERSON_TYPE, maintaining the old 1=>1 relationship, but allowing ptu to have 1=>many ..

Here, People_f.person_type_id is NOT the (as i understand) correct value .. and i was trying to use :

HR_PERSON_API.update_person
(p_validate => b_validate --in boolean default false
,p_effective_date => x.effective_start_date --in date
,p_datetrack_update_mode => l_datetrack_update_mode --in (CORRECTION) varchar2
,p_person_id => x.person_id --in number
,p_object_version_number => x.object_version_number --in out nocopy number
,p_person_type_id => 238

etc to rectify the issue .. The api is taking no account of the new person type id, but leaving it at the original value ..

There is, of course UPDATE per_all_people_f
...

but the system is ONDELAY .. so i'd never manage - unless i buried it as HRDPP - eh Clive ?

.. anyway - does anyone have anymore tactical solutions to this little issue of mine ..

All the best

Neill Atkins

Neill, do you get any error messages?

I've been looking at our (11.5) version of the API here (file name peperapi.pkb, v 115.42 for reference), and from what I can see, it does the following in respect of person_type_id validation:

1. Try to find the person_type_id parameter value, in the PTU table for that person as at the effective date. If not found, then <old_pt_id> is set to null

2. Try to find the system_person_type for the person_type_id parameter value in PER_PERSON_TYPES (ie straightforward validation of the supplied value)

3. If the <old_pt_id> value from (1) above is null, then:
3.1 If the system_person_type is a composite, e.g. EMP_APL then raise an error PER_289965_COMP_PER_TYPE_INVLD
3.2 If the system_person_type from (2) is not found in the list of PTUs for the person, then raise an error PER_289603_CKW_INV_PERSON_TYPE
3.3 If we're still ok at this stage, maintain the PTU by calling hr_per_type_usage_internal.maintain_person_type_usage

So, does that help any?

Alternatively just do a Datapump Hack! Erm... apparently.

Hi Young Man .. Thanks for the feedback ..

We are : $Header: peperapi.pkb 115.38 2006/02/15 00:58:56 agolechh ship $ */

.. so not far behind - but same validation after user_hook and the :
per_per_upd.upd
(p_person_id => p_person_id
,p_effective_start_date => l_effective_start_date
,p_effective_end_date => l_effective_end_date
-- ,p_person_type_id => l_person_type_id1
,p_last_name => p_last_name


.. and I get no error messages ..

at no point is this updating the person type in the per_all_people_f and even the person_type_id in the call to the .upd is commented out!!

As usual if i update a value via the professional form - the person type in the per_all_people_f gets updated and "corrected"

.. not actually using DP here - just doing a few data fixes - so this could be a challange - unless there is a HR_UPDATE_THE PERSON_TYPE_API somewhere

Neill

Neill mate

I've had a look, and there doesn't seem to be a specific api for this. I think the only time this is going to change, is if there is a change of circumstances such as 'hire_applicant' or 'terminate_employee' etc. I would imagine that changes to the internal person_type_id on the person row would be inherent within those processes.

As an aside, what actually are you seeking to do?

.. The person_type_id in the Per_all_people_f table is wrong ..

Someone in the past has changed the ptu and left about 7000 rows in per_all_people that relate to non system default person types ..

.. i am about to try using the per_per_upd.upd() as a test here .. (this is called by the main API (as above) the person_type_id commented out)
:-)
.. CORRECTIONS via the screen maintain it for us and provide the functionality i seek ..

N

<dons tin hat, and sells shares in Lloyds Register>

.. what shares !! Its a charity !!

.. I have used HR_PERSON_API.update_person
(p_validate => b_validate --in boolean default false
,p_effective_date => x.effective_start_date --in date
,p_datetrack_update_mode => l_datetrack_update_mode --in varchar2
,p_person_id => x.person_id --in number
,p_object_version_number => x.object_version_number --in out nocopy number
,p_last_name => x.last_name --in varchar2 default hr_api.g_varchar2
,p_employee_number => x.employee_number --in out nocopy varchar2
,p_effective_start_date => l_effective_start_date -- out nocopy date
,p_effective_end_date => l_effective_end_date -- out nocopy date
,p_full_name => l_full_name -- out nocopy varchar2
,p_comment_id => l_comment_id -- out nocopy number
,p_name_combination_warning => l_name_combination_warning -- out nocopy boolean
,p_assign_payroll_warning => l_assign_payroll_warning -- out nocopy boolean
,p_orig_hire_warning => l_orig_hire_warning -- out nocopy boolean
) ;



PER_PER_UPD.upd
( p_person_id => x.person_id -- in number,
, p_effective_start_date => l_effective_start_date -- out nocopy date,
, p_effective_end_date => l_effective_end_date -- out nocopy date,
, p_person_type_id => 238 -- in number default hr_api.g_number,
, p_applicant_number => x.applicant_number -- in out nocopy varchar2,
, p_comment_id => l_comment_id -- out nocopy number,
, p_current_applicant_flag => l_current_applicant_flag -- out nocopy varchar2,
, p_current_emp_or_apl_flag => l_current_emp_or_apl_flag -- out nocopy varchar2,
, p_current_employee_flag => l_current_employee_flag -- out nocopy varchar2,
, p_employee_number => x.employee_number -- in out nocopy varchar2,
, p_full_name => l_full_name -- out nocopy varchar2,
, p_npw_number => x.npw_number -- in out nocopy varchar2,
, p_object_version_number => x.object_version_number -- in out nocopy number,
, p_effective_date => x.effective_start_date -- in date,
, p_datetrack_mode => l_datetrack_update_mode -- in varchar2,
, p_validate => b_validate -- in boolean default false,
, p_name_combination_warning => l_name_combination_warning -- out nocopy boolean,
, p_dob_null_warning => l_assign_payroll_warning -- out nocopy boolean,
, p_orig_hire_warning => l_orig_hire_warning -- out nocopy boolean
);


.. and all seems to work ok .. if anyone is interested in future ..


N

Try telling that to Adam Faith!!!!! (dredging up an old story about 'Names' losing millions on dodgy Insurance companies of a vaguely Scottish persuasion etc)

Well done that man...

Tell me, you didn't hear a bell ringing when the script finished, did you?

The Lutine Bell

.. only bell i hear is at home time ..

Late to the party as usual....

We have a constant stream of issues/data fixes for this sort of thing. Its amazing what damage unleased users can do to a system when no-one is looking.

We've found that providing the person-type on the PER_ALL_PEOPLE_F table is some form of valid employee type then the system dont seem to care that it may be mismatched with PPTU.

Our issues seem to centre on PPTU suddenly "losing" the employee person type entry - which causes all sorts of chaos.

Happy boating