Search Results delete_offer_assignment

Overview

IRC_OFFERS_API is the Oracle iRecruitment offer management application programming interface supplied by Oracle Applications (APPS schema) within Oracle E-Business Suite. In the 12.1.1 and 12.2.2 releases, the package body iriofapi.pkb encapsulates the business rules governing the creation, modification, lifecycle state transition, and deletion of employment offers generated for applicants. It provides a programmatic alternative to the iRecruitment offer entry forms, centralizing validation, workflow notification, and the synchronization of offer data with Oracle HRMS assignment records.

The package is classified as an API, meaning its procedures constitute a controlled, supported interface for external callers. Direct DML against the underlying tables is discouraged; callers are expected to invoke the API so that HRMS date-tracked entity rules, object version checks, and status history logging are applied consistently.

Key Procedures and Functions

The documented interface exposes eleven procedures and functions:

• CREATE_OFFER — inserts a new offer record for an applicant.
• UPDATE_OFFER — modifies the attributes of an existing offer.
• DELETE_OFFER — removes an offer record.
• CLOSE_OFFER — transitions an offer to its closed state.
• HOLD_OFFER — places an active offer on hold, suspending further processing.
• RELEASE_OFFER — removes a hold and returns the offer to active processing.
• CREATE_OFFER_ASSIGNMENT — creates the HRMS assignment that backs an offer.
• UPDATE_OFFER_ASSIGNMENT — modifies the assignment associated with an existing offer. This is the procedure targeted by the query "update_offer_assignment." It updates the corresponding PER_ALL_ASSIGNMENTS_F row, which is date-tracked and version-controlled.
• DELETE_OFFER_ASSIGNMENT — removes the assignment linked to an offer.
• UPLOAD_OFFER_LETTER — attaches or uploads the offer letter document for a given offer.
• OTHER_EXTENDED_OFFERS_COUNT — a function returning the count of other extended offers, supporting validation and reporting logic.

An internal helper, create_offer_assignment_copy, duplicates an offer assignment from a source assignment identifier, which may be either the applicant assignment or a previous offer assignment. It accepts a validation flag, an effective date, a source assignment identifier, and returns the new offer assignment identifier. This helper is not part of the public documented interface but is essential to assignment propagation.

Tables Accessed

The package reads and writes a defined set of tables through APPS synonyms:

• IRC_OFFERS — the primary offer entity, holding offer header attributes.
• IRC_ASSIGNMENT_STATUSES and IRC_OFFER_STATUS_HISTORY — track offer status values and the audit trail of status transitions performed by CLOSE_OFFER, HOLD_OFFER, and RELEASE_OFFER.
• PER_ALL_ASSIGNMENTS_F — the date-tracked HRMS assignment table written by the assignment procedures, including UPDATE_OFFER_ASSIGNMENT.
• PER_ALL_PEOPLE_F — supplies applicant person records for assignment construction.
• PER_ASSIGNMENT_STATUS_TYPES — validates assignment status values.
• PER_PAY_PROPOSALS — stores proposed salary information tied to the offer.
• PER_VAC_LINKED_ASSIGNMENTS — links assignments to vacancies in the recruitment model.
• FND_USER — resolves the acting user for audit and notification purposes.
• HR_API_TRANSACTIONS — supports HRMS API transaction handling and error context.
• WF_NOTIFICATIONS — used when offer actions trigger workflow notifications.

Usage Notes

IRC_OFFERS_API is normally invoked indirectly by the iRecruitment offer entry forms and the recruitment concurrent programs rather than by end users. Eight other packages reference it, indicating that offer processing is consumed by higher-level recruitment flows, including candidate selection and onboarding.

Custom code that needs to change an offer assignment should call UPDATE_OFFER_ASSIGNMENT instead of issuing DML against PER_ALL_ASSIGNMENTS_F. Because the assignment table is date-tracked, callers must supply appropriate effective dates; invalid or overlapping dates will cause the API to raise validation errors. Callers should also handle the standard HRMS API error stack and honor object version numbers to avoid lost updates.