Search Results irc_variable_comp_element_be1




Overview
Explore in AI Chat

Overview

IRC_VARIABLE_COMP_ELEMENT_BE1 is a server-side PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Oracle iRecruitment application family (indicated by the IRC prefix) and functions as a Business Event entity package that supports variable compensation processing against a vacancy record. In Oracle Workflow and Business Event terminology, a "BE" suffix designates an entity package whose procedures are invoked as business event subscription handlers or as API wrappers that publish workflow events.

The package is classified under the ETRM API classification OTHER, meaning it is not a formally published, freely extensible public API, but rather a generated internal interface. The header timestamp and the boilerplate header comment (hrapiwfe.pkb 120.4 2008/02/15, Code generated on 06/11/2008) confirm that the stub was machine-generated from the HR API generator framework, which produces thin wrappers around business logic packages. This reinforces the read-only, integration-oriented nature of the package: it exposes a single entry point that external callers use to record or trigger variable compensation changes on a vacancy, rather than containing the full business logic itself.

Key Procedures and Functions

The ETRM metadata documents exactly one procedure in this package: CREATE_VARIABLE_COMPENSATION_A. The trailing "_A" follows the HRMS API naming convention for an "API" (as opposed to "_BE" business-event) entry point, and the procedure is designed to create a variable compensation element association for a vacancy. Based on the generated source signature, the procedure accepts parameters covering the vacancy identifier, the variable compensation lookup value, the effective date of the change, and an object version number used for optimistic locking and concurrency control.

No functions are documented in this package. Callers should treat CREATE_VARIABLE_COMPENSATION_A as the only supported entry point and must supply the object version number returned by prior reads to avoid concurrent-update conflicts. Because the procedure is generated, its internal logic is delegated to the underlying iRecruitment business logic layer; direct row-level changes to the underlying tables are discouraged.

Tables Accessed

The metadata identifies three referenced objects via APPS synonyms:

  • PER_WF_EVENTS_S — the workflow events sequence, indicating that the procedure raises a business event (variable compensation created) that Oracle Workflow subscribers can consume for downstream notifications or integrations.
  • DBMS_LOB — the built-in package used for large object handling, typically to read or write the event payload or XML message associated with the raised event.
  • DUAL — the standard single-row utility table, used for PL/SQL expressions such as sequence value retrieval or date computations.

The absence of direct table DML targets in the documented synonym list indicates that the actual insert into the variable compensation storage tables is performed by the delegated business logic rather than within this wrapper. The package's visible database interaction is therefore event publication and LOB assembly.

Usage Notes

IRC_VARIABLE_COMP_ELEMENT_BE1 is typically invoked indirectly by the iRecruitment forms and concurrent programs that manage vacancy compensation, or by business event subscriptions configured in Oracle Workflow. It is referenced by one other package in the ETRM repository, indicating a layered calling chain in which a higher-level business-event package delegates to this entity wrapper.

Custom code may call CREATE_VARIABLE_COMPENSATION_A when integrating external recruitment or HR systems, but because the object is not a certified public API, such callers must accept the risk of signature changes between patch levels and must supply valid effective dates and object version numbers. In Release 12.2.2 the package behaves identically to 12.1.1 for this documented procedure, as no functional changes to the signature are recorded in the metadata.