Search Results igs_ca_inst_pkg




Overview
Explore in AI Chat

Overview

IGS_FI_LB_FCIS_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the ETRM metadata as an OTHER-type API. It belongs to the Oracle Student System (formerly Student Systems/IGS) family of packages and supports the FCIS (Financial Charge/Credit Item Set) entity within the Financials for Institutions (FI) module. The package encapsulates the data manipulation logic required to maintain the relationship between charge or credit item sets and the calendar instances to which they apply, as evidenced by its references to IGS_FI_LB_FCIS and IGS_CA_INST_ALL. In the Oracle EBS 12.1.1 and 12.2.2 releases the package is deployed as a VALID object, and the metadata documents nine procedures/functions that implement standard row-level DML, validation, and pre-DML processing. The object is tightly coupled with IGS_CA_INST_PKG, which references it, indicating that calendar instance operations may trigger or depend on FCIS-related logic maintained here.

Key Procedures and Functions

The package exposes the following documented procedures/functions. Parameter lists are not reproduced here, as the ETRM metadata documents only their names and roles.

  • INSERT_ROW — Inserts a new FCIS/calendar-instance association record into the underlying table.
  • LOCK_ROW — Acquires a row-level lock for a specified record to support concurrent update safety.
  • UPDATE_ROW — Updates an existing FCIS association record.
  • ADD_ROW — Adds a row through the higher-level DML path, typically orchestrating validation and key assignment prior to insertion.
  • DELETE_ROW — Removes an FCIS association record.
  • GET_PK_FOR_VALIDATION — Retrieves the primary key value for validation purposes.
  • GET_UK_FOR_VALIDATION — Retrieves the unique key value for validation purposes.
  • GET_FK_IGS_CA_INST — Retrieves the foreign key referencing the calendar instance, enabling callers to resolve or verify the parent calendar-instance context.
  • BEFORE_DML — Executes pre-DML processing (such as WHO column population and audit setup) before insert, update, or delete operations.

The procedure set follows the standard Oracle EBS table-handler pattern: public DML entry points (INSERT_ROW, UPDATE_ROW, DELETE_ROW), a locking routine (LOCK_ROW), validation helpers (GET_PK_FOR_VALIDATION, GET_UK_FOR_VALIDATION, GET_FK_IGS_CA_INST), and an internal trigger-style routine (BEFORE_DML).

Tables Accessed

The package reads and writes through APPS synonyms on two documented tables:

  • IGS_FI_LB_FCIS — The primary base table storing charge/credit item set records. All row insert, update, and delete operations target this table.
  • IGS_CA_INST_ALL — The calendar instance table. It is accessed to resolve, validate, or check the foreign-key association between an FCIS record and its calendar instance, as indicated by GET_FK_IGS_CA_INST.

The package also references SYS.STANDARD, the default PL/SQL package providing base language functionality such as TO_CHAR and similar built-ins.

Usage Notes

IGS_FI_LB_FCIS_PKG is typically invoked indirectly rather than directly by end users. The metadata shows it is referenced by one other package, IGS_CA_INST_PKG, meaning calendar instance processing may call into this package to coordinate FCIS-dependent data. It is also self-referenced within its own schema. Typical invocation scenarios include:

  • Forms-based maintenance — Oracle Student System forms that maintain FCIS or calendar-instance setup call the DML procedures to persist changes.
  • Package-to-package integration — IGS_CA_INST_PKG invokes FCIS routines when calendar instance operations require FCIS synchronization.
  • Custom extensions — Customer-developed concurrent programs or APIs may call the validation helpers to obtain primary, unique, or foreign-key values before issuing their own DML.

Because the package uses row locking and a BEFORE_DML hook, callers should follow the standard pattern of invoking LOCK_ROW before UPDATE_ROW or DELETE_ROW, and should not bypass BEFORE_DML when inserting or updating. Direct table manipulation outside the package should be avoided to preserve WHO column integrity and validation consistency. The object is documented as VALID in both 12.1.1 and 12.2.2, and its dependency structure is unchanged across those releases.