Search Results igs_or_phones_pkg

Overview

IGS_OR_PHONES_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema. It belongs to the Oracle Student System / Oracle iLearning family of objects (the IGS prefix), specifically the "OR" module component concerned with capturing and maintaining telephone and contact-point information for students, applicants, and related parties. Its role is to provide a controlled data-access layer—commonly referred to as a table handler—over the Oracle Trading Community Architecture (TCA) contact point tables, allowing other EBS modules to create, amend, and remove telephone records without issuing direct DML against the underlying base tables.

Within the ETRM 12.1.1 repository the package carries a status of VALID and is classified under the generic API category OTHER, indicating that it is an internal table-handling utility rather than a formally published, versioned public API. It is instantiated in both its specification and body forms, and its dependency footprint is deliberately small.

Key Procedures and Functions

The ETRM metadata documents three procedures in the package specification:

• INSERT_ROW — Inserts a new contact-point record representing a telephone number. It supplies the mandatory columns required by the owning entity and is the entry point used when a new phone entry is created for a party or contact.
• UPDATE_ROW — Modifies an existing contact-point row, typically to change the phone number, its purpose or type, or its primary/active flags.
• DELETE_ROW — Removes a contact-point record, either physically or by applying the appropriate end-dating logic consistent with the surrounding seed data.

No parameter lists are published in the metadata; the procedures follow the conventional EBS table-handler pattern of accepting the primary/foreign key identifiers of the record along with the individual column values, and exposing a standard outcome indicator such as a return status or a success flag. The package also exposes its own body-level dependencies, including self-references, which is typical where private helper routines are declared inside the body.

Tables Accessed

The package operates against the following tables, reached through APPS synonyms:

• HZ_CONTACT_POINTS — the TCA base table holding all contact-point records, of which telephone entries are one contact-point type. This is the primary target of the insert, update, and delete operations.
• HZ_CONTACT_POINTS_S — the corresponding TCA secondary/"_S" table used to store additional contact-point attributes. The package maintains this alongside the base row to keep the telephone record complete and consistent.
• DUAL — the standard single-row utility table, used for scalar evaluations and default-value derivation within the procedural logic.

No other application tables are recorded as dependencies, confirming that the package's scope is restricted to telephone contact-point maintenance and does not extend to party, address, or relationship data.

Usage Notes

IGS_OR_PHONES_PKG is an internal implementation package rather than a standalone user-facing API. It is referenced by at least one other package in the schema, IGS_OR_INST_IMP_003_PKG, which lies in the institution/import area of the IGS module. This indicates that telephone data is loaded or maintained indirectly—most commonly as part of a broader import, conversion, or data-capture process—with the import package delegating row-level phone maintenance to IGS_OR_PHONES_PKG.

In practice the package is invoked from the surrounding IGS forms and concurrent programs, and from custom extensions that need to write telephone records while respecting TCA integrity rules. Because it is not a published API, it should not be called directly from customer code without change-control review: its signature and behaviour are not guaranteed across patch levels, and all writes should remain inside the same transaction as the calling business process. Dependency on SYS.STANDARD only confirms that no external application packages are required to compile it, keeping deployment simple and its failure surface narrow.