Search Results update_offer_a

Overview

APPS.IRC_OFFERS_BK2 is a generated PL/SQL package body belonging to the Oracle iRecruitment (IRC) application module. It is derived from the IRC_OFFERS API family and forms part of the offers management layer within Oracle E-Business Suite 12.1.1 and 12.2.2. The package encapsulates the business logic required to create, maintain, and update offer records held against applicants and assignments in the recruitment cycle. It operates in close conjunction with the offer entity tables owned by the IRC schema and is exposed to the application through the APPS synonym layer.

The "_BK2" suffix identifies it as a generated "book" or hook package. Oracle HRMS and iRecruitment APIs are routinely pre-processed to produce companion hook packages that allow customer extensions to be attached to standard business events without modifying Oracle-owned code. The header comment confirms this: the code was generated by the "Oracle HRMS API Hook Pre-processor" and carries a version stamp of iriofapi.pkb 120.24. The package is therefore an extension point rather than the primary transactional entry point.

Key Procedures and Functions

• UPDATE_OFFER_A — The "after" hook procedure for the offer update business event. It executes after the standard update logic has completed and accepts a large parameter set mirroring the offer record, including the effective date, offer identifier and version, latest-offer flag, offer status, discretionary job title, offer extension method, respondent and expiry information, proposed start date, letter tracking and postal details, applicant and offer assignment identifiers, address and template identifiers, letter file attributes, and the thirty descriptive flexfield attribute columns. It also receives the object version number used for optimistic locking.
• UPDATE_OFFER_B — The "before" hook procedure for the same event. It is invoked prior to the standard update processing, allowing validation, derivation, or defaulting logic to run against the incoming offer data before it is written.

Both procedures are name-matched to the update offer operation and are intended for customer or partner extension code. No independent business logic is documented as residing in the shipped body itself.

Tables Accessed

The documented metadata does not enumerate tables referenced through APPS synonyms. As a hook package generated for the IRC_OFFERS API, the shipped body performs no direct DML of its own; instead, the base API performs the inserts and updates against the iRecruitment offer entity tables. Any table access occurs only where a customer has inserted custom code into the hook bodies. The UPDATE_OFFER_A parameter list indicates the attributes that flow through the update, including offer status, letter tracking, assignment linkage, and flexfield columns.

Usage Notes

IRC_OFFERS_BK2 is not normally called directly. It is executed automatically by the IRC_OFFERS API whenever an offer update is processed, whether initiated from the iRecruitment Recruiter or Manager responsibility forms, from a concurrent program, or from custom code that invokes the parent API. The ETRM metadata records that the package is referenced by one other package, consistent with the standard pattern in which the main API package calls its before and after hooks.

Because both hook procedures are stubs in the delivered product, the practical use of IRC_OFFERS_BK2 is as a placeholder for extensions. A typical customisation copies the body into a customer-owned package, adds validation or integration logic to UPDATE_OFFER_B and UPDATE_OFFER_A, and registers the replacement so that the hook is invoked. Any such change must preserve the documented signatures exactly, since the calling API supplies every parameter positionally. Customisations should also be re-applied following patches or upgrades, as the generated hook bodies are replaced when Oracle re-runs the API hook pre-processor.