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.

[Home] [Help]

APPS.HR_PROCESS_PERSON_SS dependencies on PER_PERSON_TYPE_USAGES_F

Line 188: FROM per_person_type_usages_f ptu,

184: ,p_effective_date in date)
185: IS
186:
187: SELECT ptu.person_type_id
188: FROM per_person_type_usages_f ptu,
189: per_person_types ppt
190: WHERE ptu.person_id = p_person_id
191: AND p_effective_date between ptu.effective_start_date
192: and ptu.effective_end_date

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

1857: ---------------------------------------------------------------------------
1858: -- Bug 1937643 Fix Begins - 08/04/2002
1859: -- With the PTU model, the per_all_people_f.person_type_id stores only the
1860: -- default user flavor of the system_person_type. The true user flavor
1861: -- for the system_person_type is stored in per_person_type_usages_f table.
1862: -- Since the current Personal Information Basic Details region and the
1863: -- New Hire page does not allow a user to choose any user flavor, so we'll
1864: -- zap the p_person_type_id to hr_api.g_number value when it is not an
1865: -- applicant when calling the hr_person_api.update_person. That way, the api

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

1863: -- New Hire page does not allow a user to choose any user flavor, so we'll
1864: -- zap the p_person_type_id to hr_api.g_number value when it is not an
1865: -- applicant when calling the hr_person_api.update_person. That way, the api
1866: -- will understand that the person_type is not changed and will not update
1867: -- the person_type_id in per_person_type_usages_f table as is. If we pass
1868: -- the per_all_people_f.person_type_id to the api, the person_type_id in
1869: -- per_person_type_usages_f table will be updated with that value which will
1870: -- overwrite the true user flavor of the system person type with the
1871: -- default user flavor person type. This may not be desirable.

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

1865: -- applicant when calling the hr_person_api.update_person. That way, the api
1866: -- will understand that the person_type is not changed and will not update
1867: -- the person_type_id in per_person_type_usages_f table as is. If we pass
1868: -- the per_all_people_f.person_type_id to the api, the person_type_id in
1869: -- per_person_type_usages_f table will be updated with that value which will
1870: -- overwrite the true user flavor of the system person type with the
1871: -- default user flavor person type. This may not be desirable.
1872: -- When we allow a user to select user flavors of person type in New Hire
1873: -- or Basic Details page, the code to pass hr_api.g_number in

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

5425: ---------------------------------------------------------------------------
5426: -- Bug 1937643 Fix Begins - 08/04/2002
5427: -- With the PTU model, the per_all_people_f.person_type_id stores only the
5428: -- default user flavor of the system_person_type. The true user flavor
5429: -- for the system_person_type is stored in per_person_type_usages_f table.
5430: -- Since the current Personal Information Basic Details region and the
5431: -- New Hire page does not allow a user to choose any user flavor, so we'll
5432: -- zap the p_person_type_id to hr_api.g_number value when it is not an
5433: -- applicant when calling the hr_person_api.update_person. That way, the api

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

5431: -- New Hire page does not allow a user to choose any user flavor, so we'll
5432: -- zap the p_person_type_id to hr_api.g_number value when it is not an
5433: -- applicant when calling the hr_person_api.update_person. That way, the api
5434: -- will understand that the person_type is not changed and will not update
5435: -- the person_type_id in per_person_type_usages_f table as is. If we pass
5436: -- the per_all_people_f.person_type_id to the api, the person_type_id in
5437: -- per_person_type_usages_f table will be updated with that value which will
5438: -- overwrite the true user flavor of the system person type with the
5439: -- default user flavor person type. This may not be desirable.

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

5433: -- applicant when calling the hr_person_api.update_person. That way, the api
5434: -- will understand that the person_type is not changed and will not update
5435: -- the person_type_id in per_person_type_usages_f table as is. If we pass
5436: -- the per_all_people_f.person_type_id to the api, the person_type_id in
5437: -- per_person_type_usages_f table will be updated with that value which will
5438: -- overwrite the true user flavor of the system person type with the
5439: -- default user flavor person type. This may not be desirable.
5440: -- When we allow a user to select user flavors of person type in New Hire
5441: -- or Basic Details page, the code to pass hr_api.g_number in