Search Results irc_party_swi




Overview

IRC_PARTY_SWI is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the iRecruitment application's party and user provisioning model. Its role is to bridge recruitment candidate records and Oracle EBS system users, orchestrating the creation, update, and self-service registration of registered users, partial users, and internal candidates. The package is classified under the ETRM "OTHER" API category, which indicates that it is a supporting internal API rather than a formally published public interface, and it is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2. It sits logically between iRecruitment business flows and the underlying Oracle HRMS person model, delegating person record creation and maintenance to HR_API while managing the recruitment-facing user registration lifecycle. The package is referenced by no other packages according to the ETRM dependency report, meaning it is generally a consumer of platform APIs rather than a building block for additional shared code, though its own body is listed as referencing itself under the dependency tree.

Key Procedures and Functions

The package exposes nine documented procedures and functions, each addressing a distinct stage of recruitment user provisioning.

  • CREATE_CANDIDATE_INTERNAL — Creates an internal candidate record, typically for existing employees or contingent workers participating in an internal recruitment process.
  • CREATE_REGISTERED_USER — Establishes a fully registered external user, including the associated party and person information required for recruitment participation.
  • REGISTERED_USER_APPLICATION — Handles the association between a registered user and an application submission, supporting the apply-to-job workflow.
  • UPDATE_REGISTERED_USER — Maintains and modifies details of an existing registered user profile.
  • CREATE_USER — Provides the general user creation routine used in standard recruitment registration paths.
  • SELF_REGISTER_USER — Supports the self-service registration flow through which external applicants create their own iRecruitment accounts.
  • GET_FIRST_PAGE — Retrieves the initial page or entry state used during user registration or onboarding navigation.
  • CREATE_PARTIAL_USER — Creates a partially completed user record, allowing a candidate to be captured before full registration is finalized.
  • CREATE_USER_BYREFERRAL — Handles user creation originating from an employee referral, linking the referred applicant to the referring party.

Tables Accessed

Through APPS synonyms, the package interacts with both HRMS and Oracle Application Object Library data. PER_ALL_PEOPLE_F is the core HRMS date-tracked table holding person records; IRC_PARTY_SWI reads and writes it to create and maintain candidate and user identities in coordination with HR_API. FND_FORM_FUNCTIONS, FND_MENUS, FND_MENU_ENTRIES, and FND_RESPONSIBILITY are Oracle Application Object Library tables used to manage the function, menu, and responsibility assignments required when provisioning a usable EBS user account. This combination reflects the package's dual responsibility: establishing the HRMS person and configuring the application security and navigation artifacts the new user requires.

Usage Notes

IRC_PARTY_SWI is typically invoked indirectly through iRecruitment self-service and administrative flows rather than from custom code. The self-registration, referral, internal candidate, and partial-user functions are triggered from the iRecruitment web interface as applicants and recruiters progress through registration and application steps, and the responsibility and menu tables confirm that the package participates in granting access to the recruitment responsibility after user creation. Because the dependency metadata does not list any packages referencing IRC_PARTY_SWI, it should be treated as an internal implementation API. Customizations that call it directly must account for its dependency on HR_API and PER_ALL_PEOPLE_F and follow Oracle's documented parameters, since parameter signatures are not published in the ETRM and cannot be assumed.