Results for “igs_ps_govt_atd_mode”

28 results




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

Overview

The IGS_PS_GOVT_ATD_MODE table belongs to the IGS (Student System) product family within Oracle E-Business Suite. It is documented as an obsolete reference entity that describes the DETYA set of attendance modes, such as 1 – Internal and 2 – External. DETYA (now the Australian Department of Education) reporting required institutions to classify each student's attendance pattern against a government-defined code set, and this table stored that canonical code list so that student enrollment records could carry a validated attendance mode value.

As a lookup or validation table, IGS_PS_GOVT_ATD_MODE does not hold transactional student activity itself. Instead, it supplies the permitted values and their human-readable descriptions that other enrollment-facing tables reference. The documented ETRM classification for this object is standalone, which suggests, as a modeling heuristic, that it maps most naturally to a reference hub (or a small satellite attached to one) rather than to a link or a transaction satellite, because the FK mining found no incoming or outgoing relationships within the mined structure.

The documentation notes that the object is not implemented in the surveyed database. In Oracle EBS 12.1.1 and 12.2.2 environments, this typically indicates the table exists in the shipped schema definition but was disabled, superseded, or regionally scoped out of the delivered instance.

Key Information Stored

The table is documented with eight physical columns, with the most significant being:

  • GOVT_ATTENDANCE_MODE – The business-key column holding the DETYA attendance mode code (for example, 1 for Internal, 2 for External).
  • DESCRIPTION – The textual label associated with each attendance mode code, used in list-of-values displays and reports.
  • CLOSED_IND – A flag indicating whether the attendance mode is still active and selectable, or retired from use.
  • CREATED_BY – The user ID that created the row, populated by the standard WHO columns.
  • CREATION_DATE – The timestamp at which the row was inserted.
  • LAST_UPDATED_BY – The user ID responsible for the most recent change.
  • LAST_UPDATE_DATE – The timestamp of the most recent update.
  • LAST_UPDATE_LOGIN – The login context of the last update, used for auditing in multi-user environments.

The surrogate primary key is defined by the constraint/index IGS_PS_GOVT_ATD_MODE_PK, which is satisfied by the GOVT_ATTENDANCE_MODE column. A separate unique index, IGS_PS_GOVT_ATD_MODE_U1, also covers GOVT_ATTENDANCE_MODE, confirming it as the business-key candidate. In practice the surrogate and business key coincide; there is no independent system-generated identifier beyond the government code itself.

Common Use Cases and Queries

The principal use case is validation and presentation of attendance mode codes on student enrollment and government reporting screens. A typical lookup query retrieves active codes for a list of values:

SELECT govt_attendance_mode, description
FROM   igs_ps_govt_atd_mode
WHERE  NVL(closed_ind, 'N') = 'N'
ORDER BY govt_attendance_mode;

For DETYA statistical extracts, the table is joined to student unit attempt or enrollment records so that each reported record carries the correct attendance mode description. A reverse-lookup pattern resolves a code captured on a transactional row back to its description for reconciliation against government submissions. Because CLOSED_IND exists, audits frequently query historical rows regardless of status to determine which codes were valid at a given point in time, an important consideration when the underlying code set has been revised between reporting years.

Related Objects

Although the mined relationship profile labels this table standalone, it functions semantically as a validation source for student enrollment data. The most significant objects that reference or depend on it include:

Because the table is documented as obsolete and unimplemented, integrators should confirm whether a given EBS instance populates it before building dependencies on it.