Search Results igs_ps_emp_cats_wl_pkg

Overview

The APPS.IGS_PS_EMP_CATS_WL_PKG package body is a server-side PL/SQL component within the Oracle E-Business Suite (EBS) Student Systems / Higher Education product family, specifically the Student Records and prospect/application management area (IGS prefix). It provides the programmatic interface for maintaining records in the IGS_PS_EMP_CATS_WL entity, which stores employer categories associated with the workplace or employer records held against a prospect, applicant or student. In EBS 12.1.1 and 12.2.2 the package is delivered in the APPS schema with a VALID status and is classified by ETRM as an OTHER API rather than a formal public API, meaning it is intended for internal consumption by the standard IGS forms, concurrent processes and dependent packages rather than for direct customer extension.

Functionally, the package encapsulates the full DML lifecycle for the employer-category rows — validation, insertion, update, deletion and row locking — while delegating enrolment and messaging concerns to shared IGS infrastructure. It is one of the lowest-level building blocks in the workplace/employer sub-model and is not referenced by any other database object, confirming its role as a leaf-level maintenance package.

Key Procedures and Functions

ETRM documents eight procedures/functions within the package body. Their responsibilities are as follows:

• INSERT_ROW — Performs the core insert of a new employer-category row after the standard validation steps have completed.
• ADD_ROW — Higher-level "add" entry point that typically orchestrates key derivation and validation before delegating to INSERT_ROW.
• UPDATE_ROW — Applies changes to an existing employer-category record identified by its primary key.
• DELETE_ROW — Removes an existing employer-category record, subject to referential and validation checks.
• LOCK_ROW — Issues the row-level lock (SELECT ... FOR UPDATE) used to serialise concurrent maintenance of the same record.
• GET_PK_FOR_VALIDATION — Resolves or validates the primary key of the target row, supporting the mandatory-column and key checks performed during DML.
• GET_FK_IGS_PS_EXP_WL — Derives or validates the foreign key linking the employer-category row to its parent workplace/employer record in IGS_PS_EXP_WL.
• BEFORE_DML — Central pre-processing routine invoked ahead of insert, update and delete; it enforces mandatory values, cross-field consistency and may raise messages via FND_MESSAGE/IGS_GE_MSG_STACK.

Parameter lists are not documented in ETRM and are therefore not reproduced here.

Tables Accessed

The package operates against two documented tables, accessed through APPS synonyms:

• IGS_PS_EMP_CATS_WL — the employer-category entity itself; this is the primary DML target for insert, update, delete and lock operations.
• IGS_PS_FAC_WL — a related workplace/facility entity consulted to validate or complete the employer-category record during BEFORE_DML and key derivation.

In addition, the dependency list confirms runtime use of IGS_PS_EXP_WL (via the parent package IGS_PS_EXP_WL_PKG), IGS_PS_GEN_001 for generic IGS utilities, APP_EXCEPTION, FND_GLOBAL, FND_MESSAGE and IGS_GE_MSG_STACK for error raising and message stacking, and STANDARD.

Usage Notes

IGS_PS_EMP_CATS_WL_PKG is typically invoked indirectly: the standard IGS mantenance forms (for example the workplace/employer maintenance form) call ADD_ROW, UPDATE_ROW and DELETE_ROW in response to end-user actions, while BEFORE_DML and GET_PK_FOR_VALIDATION fire automatically as part of that processing. Concurrent programs that bulk-load or interface employer-category data may call the same entry points. Because the object is classified as OTHER rather than a public API, and because it is not referenced by any other database object, customisations should avoid direct calls and instead use the supported IGS business APIs; where direct use is unavoidable, custom code must supply the correct primary key, respect the row-locking convention established by LOCK_ROW, and handle the exceptions propagated through APP_EXCEPTION and IGS_GE_MSG_STACK. The behaviour is consistent across EBS 12.1.1 and 12.2.2.