Search Results s_adm_offer_dfrmnt_status

Overview

IGS_AD_OFRDFRMT_STAT_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the IGS – Student System product family (the Oracle Student System / recruiting and admissions module). The view exposes the set of admission offer deferment statuses used to describe the state of a deferred admission offer within the admissions workflow. It presents each status code together with its translated lookup meaning, the system default indicator, and standard Oracle audit columns. Because it is a view rather than a table, it imposes no additional storage and is intended purely for query, reporting, and integration consumption. In EBS 12.1.1 and 12.2.2 the object is delivered as VALID and is typically queried by admission staff-facing forms, concurrent programs, and custom reports that need the human-readable meaning of a deferment status rather than the internal code.

Underlying Base Objects

The view is defined over two objects in the APPS schema: the base table IGS_AD_OFRDFRMT_STAT (aliased AODS), which stores the admission offer deferment status records, and IGS_LOOKUPS_VIEW (aliased LKUPV), the standard EBS lookup view. The two are joined on lookup type and code: LKUPV.LOOKUP_TYPE is fixed to 'ADM_OFFER_DFRMNT_STATUS' and LKUPV.LOOKUP_CODE equals AODS.S_ADM_OFFER_DFRMNT_STATUS. This join pattern is the conventional Oracle EBS approach for attaching seeded lookup meanings, descriptions, and closed indicators to a coded column. The base table supplies the technical status code, description, default flag, and audit columns; the lookup view supplies the display meaning and the lookup-level closed indicator. Note that although the base table IGS_AD_OFRDFRMT_STAT is clearly referenced in the view text, the ETRM 12.2.2 metadata records "none documented" for referenced base objects, so the dependency on IGS_LOOKUPS_VIEW in particular is confirmed only from the view SQL itself.

Key Columns

• ROW_ID – The ROWID of the underlying IGS_AD_OFRDFRMT_STAT row, useful for uniquely identifying a record without relying on business keys.
• ADM_OFFER_DFRMNT_STATUS – The primary status identifier for the admission offer deferment status record.
• S_ADM_OFFER_DFRMNT_STATUS – The lookup code joined to IGS_LOOKUPS_VIEW; this is the seeded (system) status value.
• DESCRIPTION – The description stored on the base table record.
• MEANING – The translated lookup meaning from IGS_LOOKUPS_VIEW, i.e., the display text for the status.
• DSP_CLOSED_IND – The closed indicator carried on the lookup (LKUPV.CLOSED_IND), typically used to determine whether the lookup itself is inactive for display purposes.
• SYSTEM_DEFAULT_IND – Indicates whether this status is the seeded system default for new deferment records.
• CLOSED_IND – The closed indicator stored on the base table (AODS.CLOSED_IND), which governs whether the status is available for selection.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard Oracle who-columns capturing creation and last modification audit information.

Common Use Cases and Queries

Typical usage is a lookup/reference join: fetching the display meaning and closed status for admission offer deferment statuses in custom reports, LOVs, and integration extracts. A common query lists all active statuses:

SELECT ADM_OFFER_DFRMNT_STATUS, MEANING, SYSTEM_DEFAULT_IND, CLOSED_IND
FROM   APPS.IGS_AD_OFRDFRMT_STAT_V
WHERE  CLOSED_IND = 'N'
ORDER BY MEANING;

To retrieve the default status, filter on SYSTEM_DEFAULT_IND. To join deferment records to their human-readable status in admissions reporting, query this view and join back to IGS_AD_OFRDFRMT_STAT on ADM_OFFER_DFRMNT_STATUS, or use MEANING directly in output columns. Because it surfaces the lookup meaning without requiring a manual join to IGS_LOOKUPS_VIEW with the 'ADM_OFFER_DFRMNT_STATUS' lookup type, the view simplifies custom SQL and reduces the risk of missing the LOOKUP_TYPE predicate. When the metadata is limited (as noted here), always confirm column semantics against the base table DDL and ETRM in the target instance before relying on them in production code.