Results for “igs_ps_usec_charge”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The table IGS_PS_USEC_CHARGE belongs to the IGS – Student System product family within Oracle E-Business Suite. According to the ETRM documentation metadata, it is classified as obsolete and is described as a "Table for storing the data for additional charges for a Unit Section." It was designed to hold supplementary fee or charge records attached to a specific unit offering option (a "Unit Section" in IGS terminology), such as lab fees, materials charges, or other ancillary costs linked to an academic unit offering.

In Oracle EBS releases 12.1.1 and 12.2.2, this object is documented as "Not implemented in this database," meaning it is retained only as a legacy or reference artifact from earlier releases and is not actively populated or supported in current installations. Its Data Vault classification, derived heuristically from its foreign key structure, is satellite-leaning. This suggests the table behaves as a descriptive satellite attached to a parent hub anchored by the unit offering option, rather than as an independent hub or a pure linking table.

Key Information Stored

The documented metadata exposes a limited but meaningful set of columns. The most significant are:

• USEC_CHARGE_ID — the surrogate primary key, defined by the constraint IGS_PS_USEC_CHARGE_PK. This uniquely identifies each additional charge record.
• UOO_ID — the foreign key referencing IGS_PS_UNIT_OFR_OPT_ALL.UOO_ID, tying the charge to a specific unit offering option (Unit Section).
• USEC_CHARGE_CODE — a business-key attribute identifying the type or classification of the charge, participating in the unique constraint IGS_PS_USEC_CHARGE_UK alongside UOO_ID.

The unique index IGS_PS_USEC_CHARGE_UK, composed of UOO_ID and USEC_CHARGE_CODE, establishes the natural/business key. This pairing ensures that any given unit offering option can carry at most one instance of each defined charge code, preventing duplicate charge definitions for the same section.

Common Use Cases and Queries

Because the table is obsolete and not implemented in current databases, practical use cases are largely historical or migration-oriented. Nevertheless, the following patterns illustrate how it would have been queried.

Retrieving all additional charges for a given unit offering option:

SELECT usec_charge_id, uoo_id, usec_charge_code
FROM   igs_ps_usec_charge
WHERE  uoo_id = :p_uoo_id;

Joining to the parent unit offering option to resolve descriptive context:

SELECT c.usec_charge_code, o.*
FROM   igs_ps_usec_charge c,
       igs_ps_unit_ofr_opt_all o
WHERE  c.uoo_id = o.uoo_id;

Typical reporting scenarios would have included fee breakdown reports per unit section, charge-code frequency analysis for fee policy review, and migration validation scripts confirming that legacy charge data reconciles with successor fee structures. Legacy data extraction during upgrade projects is the most common current touchpoint.

Related Objects

The documented foreign key relationship identifies the principal related object:

• IGS_PS_UNIT_OFR_OPT_ALL — the parent table holding unit offering option records; joined via IGS_PS_USEC_CHARGE.UOO_ID = IGS_PS_UNIT_OFR_OPT_ALL.UOO_ID. This is the single confirmed FK relationship in the metadata.

By extension, the unit offering option is itself referenced by related IGS scheduling and enrollment constructs, so downstream historical reporting may chain through it. No additional views, APIs, or dependent tables are documented in the provided metadata; any further relationships would require verification against the specific EBS instance's data dictionary.