Search Results get_person_rec

Overview

APPS.IRC_PARTY_PERSON_UTL is a utility package body belonging to the Oracle iRecruitment (IRC) product family. Its principal business function is to synchronize and repair the relationship between Oracle Trading Community Architecture (TCA) party records stored in HZ_PARTIES and the corresponding Oracle HRMS person records stored in PER_ALL_PEOPLE_F. In Oracle EBS, iRecruitment creates party records for external applicants, prospective employees, and other non-employee users whose data originates outside the standard HR person creation path. When these party-to-person linkages become inconsistent — for example, when a party exists without a person_id, or when a person record references an obsolete party — the package's procedures detect and correct the mismatch. The package therefore acts as a data-integrity maintenance utility for the person/party model that underpins iRecruitment self-service registration, notification preferences, and applicant tracking. The $Header indicates the package has been stable since release 12.0, with no substantive change history in the 12.1.1 and 12.2.2 code lines.

Key Procedures and Functions

ETRM documents two procedures in this package:

• UPDATE_PARTY_RECORDS — The core maintenance routine. It accepts a mode parameter that controls the scope of the reconciliation. Internally it uses a PL/SQL associative array (index-by table of NUMBER) to bulk-collect party identifiers and person identifiers, then iterates over the collection to create or update the missing person records and repair party references. The documented source shows cursor logic built from unions across HZ_PARTIES, IRC_NOTIFICATION_PREFERENCES, PER_ADDRESSES, PER_PHONES, PER_PREVIOUS_EMPLOYERS, PER_QUALIFICATIONS, and PER_ESTABLISHMENT_ATTENDANCES, each contributing rows where a party_id exists but the corresponding person_id is null. Local variables track old and new row counts, business group, person type, object version number, effective dates, full name, and comment identifier, along with HRMS warning flags such as name combination, original hire, and assignment/payroll warnings. This reflects a call into the HR person creation or update APIs for each affected record.
• UPDATE_PARTY_CONC — The concurrent-program entry point. It is a thin wrapper that invokes UPDATE_PARTY_RECORDS in a mode suitable for scheduled background execution, allowing the reconciliation to run across the entire population without interactive session context.

Tables Accessed

The package reads and writes across two domains. On the TCA side it queries HZ_PARTIES to identify records created with the orig_system_reference value 'PER:IRC' and joins to HZ_PERSON_PROFILES. On the HRMS side it reads PER_ALL_PEOPLE_F (supplying object version number, effective dates, full name, and comment identifier) and the dependent person entities PER_ADDRESSES, PER_ESTABLISHMENT_ATTENDANCES, and PER_COMPETENCE_ELEMENTS. iRecruitment-owned tables including IRC_NOTIFICATION_PREFERENCES, IRC_NOTIFICATION_PREFS_S, IRC_DOCUMENTS, IRC_JOB_BASKET_ITEMS, IRC_SEARCH_CRITERIA, IRC_SEARCH_CRITERIA_S, and IRC_VACANCY_CONSIDERATIONS are referenced to collect party identifiers holding recruitment data. FND_USER and HR_ORGANIZATION_INFORMATION are consulted to resolve the user-to-person association and the business group context required when creating HR person records.

Usage Notes

IRC_PARTY_PERSON_UTL is not a public API and ETRM records zero references from other packages, confirming it is invoked internally. Normal invocation occurs through the UPDATE_PARTY_CONC concurrent program, which is typically scheduled during implementation cutover after iRecruitment data migration, or run periodically to reconcile orphaned party records generated by registration and applicant-conversion flows. Custom code should not call UPDATE_PARTY_RECORDS directly, because it relies on session context such as business group and effective date defaults and performs unrestricted DML against HZ_PARTIES and PER_ALL_PEOPLE_F. Because the package was last modified in 2005, it should be treated as legacy code: preferred remediation for missing person/party data is the supported HR and TCA public APIs, with this package reserved for bulk cleanup where no per-record API path exists.