Search Results auth_action_code

Overview

The IGS_SV_CNCL_DROP_BLW_V view is a Student System (IGS) reporting and integration object owned by the APPS schema. It is defined in Oracle E-Business Suite 12.1.1 and 12.2.2 and is documented in the ETRM as a VALID database view. Its stated purpose is to fetch details about authorization reasons that have been cancelled, specifically for the "Below" program action. The view is a filtered projection over the IGS_SV_PRGMS_INFO table, restricted to records where the program action type is a drop-below event and the authorization action code indicates a cancellation.

In the broader Enrollment Management and Student Records architecture of the IGS product family, this view serves as a simplified access layer. Consumers—such as Self-Service forms, PL/SQL packages, concurrent reporting programs, and third-party integrations—can query cancellation activity without embedding the restrictive WHERE predicate (PRGM_ACTION_TYPE = 'DB' AND AUTH_ACTION_CODE = 'C') themselves. Because it is pre-filtered, the view effectively encapsulates a specific business rule: it exposes only the drop-below authorization records whose action has been cancelled.

Underlying Base Objects

The ETRM documentation for this view identifies a single referenced base object: IGS_SV_PRGMS_INFO (aliased as PRGMS in the view text). This table stores program-level information and authorization detail for student program events, including batch identification, person identification, print form flags, authorization reasons, program start and end dates, program action types, and authorization action codes. The view performs no joins, unions, or aggregations; it is a straightforward SELECT-FROM-WHERE against this one table.

• Base table: APPS.IGS_SV_PRGMS_INFO
• Relationship: One row in the view corresponds to exactly one qualifying row in IGS_SV_PRGMS_INFO. No duplicate suppression or transformation is applied.
• Filtering logic: PRGM_ACTION_TYPE = 'DB' (drop-below) and AUTH_ACTION_CODE = 'C' (cancelled).

The ETRM metadata notes "Referenced base objects: none documented" at the view level, but the embedded view text explicitly references IGS_SV_PRGMS_INFO, which should be treated as the authoritative source for this dependency.

Key Columns

The view exposes seven columns, each derived directly (some with aliases) from the base table:

• BATCH_ID — Identifier of the processing batch under which the authorization record was created. Useful for grouping or reconciliation by run.
• PERSON_ID — The student's person identifier; the primary key into the person/student tables and the natural join key to enrollment and biographical data.
• PRINT_FORM — Flag indicating whether a printed authorization form was generated for the record.
• AUTH_REASON — Aliased from PRGMS.AUTHORIZATION_REASON; the textual or coded reason for the authorization.
• AUTH_START_DATE — Aliased from PRGMS.PRGM_START_DATE; the effective start of the authorization period.
• AUTH_END_DATE — Aliased from PRGMS.PRGM_END_DATE; the effective end of the authorization period.
• AUTH_ACTION_CODE — The authorization action code. Within this view it is always 'C', representing the cancelled authorization action. The user's search term auth_action_code maps directly to this column.

Common Use Cases and Queries

Typical scenarios include auditing cancelled drop-below authorizations, generating student notifications, and reconciling batch activity. A minimal retrieval for a specific person is:

• SELECT batch_id, person_id, auth_reason, auth_start_date, auth_end_date FROM apps.igs_sv_cncl_drop_blw_v WHERE person_id = :p_person_id;
• Batch-reconciliation query: SELECT batch_id, COUNT(*) FROM apps.igs_sv_cncl_drop_blw_v GROUP BY batch_id;
• Date-bounded reporting: SELECT * FROM apps.igs_sv_cncl_drop_blw_v WHERE auth_start_date BETWEEN :p_from AND :p_to;

Because AUTH_ACTION_CODE is hard-coded to 'C' by the view definition, additional predicates on that column are redundant. Querying this view is more efficient and less error-prone than filtering IGS_SV_PRGMS_INFO directly, and it remains consistent across both 12.1.1 and 12.2.2 releases.