Search Results igs_tr_step_note_pkg




Overview
Explore in AI Chat

Overview

The APPS.IGS_TR_STEP_NOTE_PKG package body is a core data-access and validation component of the Oracle E-Business Suite (EBS) Student Systems / Training and Registration (ETRM) module. It encapsulates the business logic required to maintain rows in the IGS_TR_STEP_NOTE entity, which associates free-text or structured notes with individual steps in a prospect or applicant workflow. In the ETRM data model, a "step" represents a discrete stage in a registration or admissions process, and notes attached to steps capture admissions officer commentary, interview outcomes, or procedural observations that must be preserved against the step record.

The package is owned by the APPS schema and is classified as OTHER under the ETRM API taxonomy, meaning it is not a published external API but an internal Table Handler (TH) package generated and maintained in the standard Oracle EBS table-handler style. Its status is VALID in both 12.1.1 and 12.2.2, confirming that it behaves consistently across both release levels. The package is referenced by four other database objects and depends in turn on a well-defined set of platform and module utilities, including FND_GLOBAL, FND_MESSAGE, APP_EXCEPTION, IGS_GE_MSG_STACK, IGS_GE_NOTE_PKG, IGS_TR_NOTE_TYPE_PKG, and IGS_TR_STEP_PKG.

Key Procedures and Functions

The package body exposes eleven documented procedures and functions that together implement the full DML lifecycle for the IGS_TR_STEP_NOTE entity:

  • INSERT_ROW — performs the physical insert of a new step-note record, populating mandatory columns and audit attributes.
  • UPDATE_ROW — applies modifications to an existing step-note row identified by its primary key.
  • DELETE_ROW — removes a step-note record, subject to the package's internal constraint validation.
  • ADD_ROW — a convenience wrapper that constructs the row payload and delegates to INSERT_ROW.
  • LOCK_ROW — issues a SELECT ... FOR UPDATE against the target row to serialize concurrent modifications before an update or delete.
  • GET_PK_FOR_VALIDATION — resolves and returns the primary key values used by downstream validation logic.
  • CHECK_CONSTRAINTS — evaluates foreign-key and business-rule constraints before DML, raising descriptive errors via FND_MESSAGE and IGS_GE_MSG_STACK when a rule is violated.
  • BEFORE_DML — a pre-processing hook invoked ahead of insert, update, and delete to apply standard WHO-column and audit population, typically using FND_GLOBAL.USER_ID and FND_GLOBAL.LOGIN_ID.
  • GET_FK_IGS_GE_NOTE — validates and returns the foreign-key reference to the general note entity.
  • GET_FK_IGS_TR_NOTE_TYPE — validates and returns the foreign-key reference to the training note type.
  • GET_FK_IGS_TR_STEP — validates and returns the foreign-key reference to the parent step record.

The three GET_FK_* helpers confirm that the package enforces referential integrity against the general note framework, the note-type lookup, and the parent step entity before any row is persisted. No parameter lists are invented here; their names and purposes are taken directly from the documented metadata.

Tables Accessed

The only base table documented as accessed through APPS synonyms is IGS_TR_STEP_NOTE. This table stores the association between a step and a note, together with note text, note type, and standard audit columns. The package reads from it during LOCK_ROW, CHECK_CONSTRAINTS, and the GET_FK_* validation routines, and writes to it during INSERT_ROW, UPDATE_ROW, and DELETE_ROW. The foreign-key lookups implicitly reference the parent entities (the general note, note type, and step) through their own packages, ensuring that a step note cannot be created against a nonexistent step or note type.

Usage Notes

IGS_TR_STEP_NOTE_PKG is an internal handler rather than a public integration point. It is normally invoked indirectly by the ETRM forms and by the four dependent packages that call it, rather than by external custom code. In a 12.1.1 or 12.2.2 environment, administrators and developers should treat it as subject to change between patches and avoid calling it directly from custom extensions unless no supported alternative exists. When troubleshooting step-note behavior — such as missing notes, lock contention on a step, or foreign-key validation errors surfacing through the message stack — the procedures CHECK_CONSTRAINTS, BEFORE_DML, and the GET_FK_* functions are the primary diagnostic entry points.