Search Results incl_wkend_duration_flag




Overview
Explore in AI Chat

Overview

IGS.IGS_EN_NSU_DLSTP_ALL is a transactional setup table within the Oracle EBS Student Systems (IGS) product family. It stores configuration records that define how enrollment deadline dates are calculated for non-standard unit sections. In the institutional enrollment model, an academic unit section may be offered outside the normal calendar structure; this table supplies the rules that determine the deadline date applied when a student enrolls in such a section. Each row represents a discrete deadline setup, keyed by a system-generated identifier and scoped to an operating unit through ORG_ID.

The table resides in the APPS_TS_TX_DATA tablespace with a PCTFREE of 10, and its unique indexes are held in APPS_TS_TX_IDX. The ETRM metadata classifies the object as hub-leaning under a heuristic Data Vault assessment. In practical modeling terms, this suggests the table may be treated as a master or reference hub for deadline setups, with downstream tables acting as satellites or links that attach additional attributes or relationships. That classification is a modeling suggestion rather than a physical constraint enforced by the schema.

Key Information Stored

The surrogate primary key is NON_STD_USEC_DLS_ID, a NUMBER(15) column documented as the system-generated unique identifier for a non-standard unit section discontinuation/deadline setup. Note that it is also the sole column of unique index IGS_EN_NSU_DLSTP_ALL_U1, so the index and the primary key are effectively coincident.

IGS_EN_NSU_DLSTP_ALL_U2 provides the meaningful business-key candidate: the composite of FUNCTION_NAME, DEFINITION_CODE, ORG_UNIT_CODE, and ORG_ID. This combination ensures that a given administrative unit status and definition level is configured only once per organizational unit. The four columns carry the following semantics: FUNCTION_NAME names an institution-defined administrative unit status; DEFINITION_CODE denotes the definition level of that status; ORG_UNIT_CODE identifies the organizational unit (a business unit of the institution); and ORG_ID is the standard operating unit identifier used throughout EBS for multi-org security.

The calculation behavior is governed by FORMULA_METHOD (Duration days or Meeting days), ROUND_METHOD (Standard Round or Always Round Up), OFFSET_DT_CODE (the anchor date, such as unit section effective start date), OFFSET_DURATION (the offset expressed as a percentage value), and INCL_WKEND_DURATION_FLAG, which indicates whether weekends are counted for the Duration days method. Standard WHO audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) complete the 15 documented columns.

Common Use Cases and Queries

Typical usage centers on validating and reporting deadline configuration. A setup review may list all active rules for an operating unit:

  • Lookup by business key: SELECT * FROM igs.igs_en_nsu_dlstp_all WHERE function_name = :p_function AND definition_code = :p_def AND org_unit_code = :p_org AND org_id = :p_org_id;
  • Listing rules per operating unit with ORG_ID filtering for multi-org reporting.
  • Joining to dependent deadline tables to trace which offsets or discontinuation records derive from a setup.
  • Auditing recent configuration changes using LAST_UPDATE_DATE and LAST_UPDATED_BY.

Because OFFSET_DURATION is documented as a percentage value and FORMULA_METHOD controls the duration basis, reporting logic that computes actual deadline dates must interpret these columns together rather than treating the offset as an absolute day count.

Related Objects

Two dependent tables reference this object through NON_STD_USEC_DLS_ID:

  • IGS.IGS_EN_DL_OFFSET_CONS — references NON_STD_USEC_DLS_ID, holding offset constraint detail tied to a setup.
  • IGS.IGS_EN_NSTD_USEC_DL — references NON_STD_USEC_DLS_ID, storing the resulting non-standard unit section deadline records.

The unique index IGS_EN_NSU_DLSTP_ALL_U2 should be consulted when designing interfaces or concurrent programs that insert setup rows, since duplicate submissions on the business key will be rejected at the database level.