Search Results irc_api

Overview

APPS.IRC_PARTY_API is the iRecruitment party and user management API within Oracle E-Business Suite, delivered as a standalone PL/SQL package. It encapsulates the creation, update, and lifecycle management of recruitment-related parties within the TCA (Trading Community Architecture) model, and of the associated Oracle Applications user accounts required to log in to iRecruitment. The package is central to both internal (employee) and external (candidate) recruitment flows, exposing a controlled interface that shields calling code from the physical data model of HZ_PARTIES, HZ_PERSON_PROFILES, PER_ALL_PEOPLE_F, and FND_USER.

The package header carries a versioned header comment (irhzpapi.pkb) indicating it is a shipped, patched Oracle module maintained across the 12.1.1 and 12.2.2 releases. Its procedures are used extensively by iRecruitment pages, self-service registration flows, and referral processing. The package also exposes utility primitives such as name-availability checks and profile existence tests that other modules rely on for validation.

Key Procedures and Functions

• CREATE_CANDIDATE_INTERNAL — Creates a candidate record for an internal applicant, accepting a business group and personal name attributes (including phonetic names and descriptive flexfield attributes), and returns the created person reference.
• CREATE_REGISTERED_USER / UPDATE_REGISTERED_USER — Create and maintain a self-registered external user, including the associated party or person profile.
• REGISTERED_USER_APPLICATION — Links a registered user to an application, supporting the association of a party with a recruitment application record.
• CREATE_USER / UPDATE_USER — Create and update the low-level Oracle Applications user (FND_USER) underlying a recruitment party.
• SELF_REGISTER_USER — Handles the self-service registration path for external candidates.
• CREATE_PARTIAL_USER — Creates a partially completed candidate/user record, allowing staged registration.
• IREC_PROFILE_EXISTS — Boolean-style check that determines whether a profile already exists for a given person or user.
• CREATE_HA_PROCESSED_USER and PROCESS_HA_RESP_CHECK — Support Hire-Applicant and responsibility-check processing flows.
• GRANT_ACCESS and ASSIGN_RESPONSIBILITY — Grant the iRecruitment responsibilities and access rights required for a user to operate within the application.
• TESTUSERNAME — Validates the availability and validity of a proposed username.
• CREATE_USER_BYREFERRAL — Creates a user record from a referral-based registration flow.
• MERGE_PROFILE — Consolidates duplicated or overlapping party or person profiles.
• VALIDATE_COPY_APPLICATIONS — Validates the copying of applications between users or profiles.
• OFR_REG_USER_APPLICATION — Manages the registered-user-to-application relationship in the Offer/application domain; this is the procedure surfaced by the user's search term.
• CREATE_LINKING — Creates the linking records that connect parties, users, and recruitment entities.

Tables Accessed

• PER_ALL_PEOPLE_F — Stores the person record for internal candidates and employees.
• HZ_PARTIES and HZ_PERSON_PROFILES — The TCA party and person profile records for both internal and external users.
• FND_USER, FND_LANGUAGES, FND_MENUS, and FND_PROFILE_OPTION_VALUES — Application user accounts, language defaults, responsibility menu wiring, and profile option settings.
• HR_ALL_POSITIONS_F, HR_ORGANIZATION_INFORMATION, and PAY_PEOPLE_GROUPS — Position, organization, and payroll people-group information used to derive the correct business group and organizational context.
• IRC_AGENCY_VACANCIES, IRC_OFFERS, IRC_OFFER_STATUS_HISTORY, IRC_SEARCH_CRITERIA, and IRC_NOTIFICATION_PREFERENCES — Recruitment-specific entities linked to the user during registration and offer processing.

Usage Notes

IRC_PARTY_API is invoked primarily by the iRecruitment self-service pages and by the recruitment administration forms and concurrent programs that on-board candidates. Custom code extending iRecruitment should call these procedures rather than inserting directly into FND_USER, HZ_PARTIES, or PER_ALL_PEOPLE_F, ensuring that the API performs all necessary validation, responsibility assignment, and profile-option setup.

Because the package is referenced by four other packages, changes to its behavior have downstream effects within the recruitment module. It is also the correct entry point for managing registered-user-to-application associations, including the OFR_REG_USER_APPLICATION routine. All calls should be made through the APPS schema with the standard FND_GLOBAL context set, as the procedures rely on the current business group and login environment.