Results for “igs_ad_ss_lookups”

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

Overview

IGS_AD_SS_LOOKUPS is a configuration table belonging to the IGS – Student System product family in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores self-service lookup data that governs the values presented to applicants and students interacting with the Student System self-service admission pages. The table defines the valid combination of admission application types and their associated self-service lookup codes, allowing the application to render context-sensitive choice lists, statuses, and coded values without hard-coding them into forms or OAF pages.

The ETRM metadata records this object as obsolete and explicitly states "Not implemented in this database" for the documented instance. This is significant: the table exists in the IGS schema definition and carries a documented physical structure of nine columns, but the specific environment from which the metadata was extracted does not contain a populated or deployed instance. Implementers encountering it should verify existence with a query against ALL_TABLES before writing dependent logic.

A heuristic Data Vault classification derived from the foreign-key structure marks this table as satellite-leaning. In Data Vault terms, it behaves less like an independent hub and more like a dependent descriptor set that qualifies a parent entity. The parent here is IGS_AD_SS_APPL_TYP, and IGS_AD_SS_LOOKUPS supplies supplemental attributes describing how each application type participates in self-service. This classification is a modeling suggestion rather than a documented architectural fact, and it aligns with the table's role as a controlled-value store rather than a transactional or master entity.

Key Information Stored

The nine documented columns divide cleanly into a composite key set and a standard EBS auditing set.

• ADMISSION_APPLICATION_TYPE – Part of the composite primary key and simultaneously a foreign key to IGS_AD_SS_APPL_TYP. It identifies which admission application type the lookup row describes, tying the lookup set to a specific self-service application context.
• SS_LOOKUP_TYPE – The second component of the primary key. It names the category or class of lookup being defined, grouping related codes under a common semantic heading.
• SS_LOOKUP_CODE – The third component of the primary key, holding the individual coded value presented or validated in the self-service flow.
• CLOSED_FLAG – A status indicator that marks whether a given lookup combination remains active or has been retired. Lookup tables in EBS conventionally retain historical rows and use a flag of this kind to suppress obsolete values from new selections while preserving them for existing records.
• CREATED_BY, CREATION_DATE – Standard who-column auditing capturing the creating user and timestamp.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard EBS update auditing that records the last modifying user, the modification timestamp, and the login identifier of the updating session.

The surrogate primary key is IGS_AD_SS_LOOKUPS_PK, which is defined over the three business columns ADMISSION_APPLICATION_TYPE, SS_LOOKUP_TYPE, and SS_LOOKUP_CODE. Because the primary key is composed entirely of meaningful business attributes, there is no separate single-column surrogate identifier; the ETRM metadata lists no unique index that differs from the primary key, meaning the composite PK is also the sole documented business-key candidate.

Common Use Cases and Queries

The principal use case is resolving the valid self-service values available for a given admission application type. A typical query joins the lookup table to its parent and filters on the closed flag.

• Retrieving active lookup codes for an application type: SELECT ss_lookup_type, ss_lookup_code FROM igs_ad_ss_lookups WHERE admission_application_type = :app_typ AND NVL(closed_flag,'N') = 'N' ORDER BY ss_lookup_type, ss_lookup_code.
• Determining which lookup types exist for a given application type: SELECT DISTINCT ss_lookup_type FROM igs_ad_ss_lookups WHERE admission_application_type = :app_typ.
• Auditing configuration changes: SELECT ss_lookup_code, last_updated_by, last_update_date FROM igs_ad_ss_lookups WHERE admission_application_type = :app_typ ORDER BY last_update_date DESC.
• Validating a submitted value: a validation query confirming that a proposed SS_LOOKUP_CODE exists with a non-closed flag before accepting applicant input.

Because the table is marked obsolete and not implemented in the documented environment, these patterns should be treated as reference logic rather than production-ready extracts. Reporting on self-service admission configuration typically requires confirming the table's presence and population first.

Related Objects

The documented foreign-key relationship anchors this table to a single parent, but the surrounding IGS_AD_SS family forms a natural dependency cluster.

• IGS_AD_SS_APPL_TYP – The referenced parent table. The join column is IGS_AD_SS_LOOKUPS.ADMISSION_APPLICATION_TYPE → IGS_AD_SS_APPL_TYP, making this the primary dependency for any query that needs application type descriptive information.
• IGS_AD_SS_LOOKUPS_PK – The composite primary key constraint over ADMISSION_APPLICATION_TYPE, SS_LOOKUP_TYPE, and SS_LOOKUP_CODE, enforcing uniqueness of each lookup combination.
• Other members of the IGS_AD_SS_* family share the self-service admission prefix and typically provide sibling lookup or configuration data consumed alongside this table.
• Self-service admission OAF pages and concurrent programs that read configured lookup values depend on the effective contents of this table for rendering choice lists.

Any extension or reporting view built over this object should preserve the composite key relationship to IGS_AD_SS_APPL_TYP as the dependable join path, since that is the only reference documented in the ETRM metadata.