eTRM uses javascript that opens and focuses a separate window to display reports. Your browser does not appear to support javascript. This should not prevent you from using eTRM but it does mean the window focus feature will not work. Please check the contents of other windows on your desktop if you click on a link that does not appear to do anything.

APPS.HR_PROCESS_PERSON_SS dependencies on PER_PERSON_TYPE_USAGES_F

Line 194: FROM per_person_type_usages_f ptu,

190: ,p_effective_date in date)
191: IS
192:
193: SELECT ptu.person_type_id
194: FROM per_person_type_usages_f ptu,
195: per_person_types ppt
196: WHERE ptu.person_id = p_person_id
197: AND p_effective_date between ptu.effective_start_date
198: and ptu.effective_end_date

Line 2118: -- for the system_person_type is stored in per_person_type_usages_f table.

2114: ---------------------------------------------------------------------------
2115: -- Bug 1937643 Fix Begins - 08/04/2002
2116: -- With the PTU model, the per_all_people_f.person_type_id stores only the
2117: -- default user flavor of the system_person_type. The true user flavor
2118: -- for the system_person_type is stored in per_person_type_usages_f table.
2119: -- Since the current Personal Information Basic Details region and the
2120: -- New Hire page does not allow a user to choose any user flavor, so we'll
2121: -- zap the p_person_type_id to hr_api.g_number value when it is not an
2122: -- applicant when calling the hr_person_api.update_person. That way, the api

Line 2124: -- the person_type_id in per_person_type_usages_f table as is. If we pass

2120: -- New Hire page does not allow a user to choose any user flavor, so we'll
2121: -- zap the p_person_type_id to hr_api.g_number value when it is not an
2122: -- applicant when calling the hr_person_api.update_person. That way, the api
2123: -- will understand that the person_type is not changed and will not update
2124: -- the person_type_id in per_person_type_usages_f table as is. If we pass
2125: -- the per_all_people_f.person_type_id to the api, the person_type_id in
2126: -- per_person_type_usages_f table will be updated with that value which will
2127: -- overwrite the true user flavor of the system person type with the
2128: -- default user flavor person type. This may not be desirable.

Line 2126: -- per_person_type_usages_f table will be updated with that value which will

2122: -- applicant when calling the hr_person_api.update_person. That way, the api
2123: -- will understand that the person_type is not changed and will not update
2124: -- the person_type_id in per_person_type_usages_f table as is. If we pass
2125: -- the per_all_people_f.person_type_id to the api, the person_type_id in
2126: -- per_person_type_usages_f table will be updated with that value which will
2127: -- overwrite the true user flavor of the system person type with the
2128: -- default user flavor person type. This may not be desirable.
2129: -- When we allow a user to select user flavors of person type in New Hire
2130: -- or Basic Details page, the code to pass hr_api.g_number in

Line 5986: -- for the system_person_type is stored in per_person_type_usages_f table.

5982: ---------------------------------------------------------------------------
5983: -- Bug 1937643 Fix Begins - 08/04/2002
5984: -- With the PTU model, the per_all_people_f.person_type_id stores only the
5985: -- default user flavor of the system_person_type. The true user flavor
5986: -- for the system_person_type is stored in per_person_type_usages_f table.
5987: -- Since the current Personal Information Basic Details region and the
5988: -- New Hire page does not allow a user to choose any user flavor, so we'll
5989: -- zap the p_person_type_id to hr_api.g_number value when it is not an
5990: -- applicant when calling the hr_person_api.update_person. That way, the api

Line 5992: -- the person_type_id in per_person_type_usages_f table as is. If we pass

5988: -- New Hire page does not allow a user to choose any user flavor, so we'll
5989: -- zap the p_person_type_id to hr_api.g_number value when it is not an
5990: -- applicant when calling the hr_person_api.update_person. That way, the api
5991: -- will understand that the person_type is not changed and will not update
5992: -- the person_type_id in per_person_type_usages_f table as is. If we pass
5993: -- the per_all_people_f.person_type_id to the api, the person_type_id in
5994: -- per_person_type_usages_f table will be updated with that value which will
5995: -- overwrite the true user flavor of the system person type with the
5996: -- default user flavor person type. This may not be desirable.

Line 5994: -- per_person_type_usages_f table will be updated with that value which will

5990: -- applicant when calling the hr_person_api.update_person. That way, the api
5991: -- will understand that the person_type is not changed and will not update
5992: -- the person_type_id in per_person_type_usages_f table as is. If we pass
5993: -- the per_all_people_f.person_type_id to the api, the person_type_id in
5994: -- per_person_type_usages_f table will be updated with that value which will
5995: -- overwrite the true user flavor of the system person type with the
5996: -- default user flavor person type. This may not be desirable.
5997: -- When we allow a user to select user flavors of person type in New Hire
5998: -- or Basic Details page, the code to pass hr_api.g_number in