Search Results ivr_display_ind




Overview
Explore in AI Chat

Overview

IGSFV_CALENDAR_PERIODS is a read-only reporting view owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It exposes the calendar instance (period) records maintained by the Oracle Student System / Student Information Management calendar infrastructure, presented in a denormalized form suitable for concurrent programs, BI Publisher reports, OBIEE extracts, and inbound/outbound integration interfaces. Each row represents a single calendar period within a calendar type, enriched with the calendar type description, the calendar status description, and prior-period reference data. The view is defined WITH READ ONLY, so it cannot be used as a DML target; it is intended exclusively for query and extraction.

The user search term ivr_display_ind maps directly to a column exposed by this view. It controls whether the period is surfaced through interactive voice response or self-service telephony channels, which is why this view is frequently queried by IVR and contact-center integration layers that need to publish only the periods flagged for voice-channel display.

Underlying Base Objects

The view is a self-join over the calendar instance table plus two lookup tables:

  • IGS_CA_INST_ALL (aliased twice as IN1 and IN2) — the calendar instance / period table, stored as an _ALL table with multi-org style partitioning semantics.
  • IGS_CA_TYPE (aliased TY3) — the calendar type definition, joined on CAL_TYPE.
  • IGS_CA_STAT (aliased ST4) — the calendar status lookup, joined on CAL_STATUS.

IN1 drives the result set. IN2 is joined with the Oracle outer-join operator (+) on both CAL_TYPE and PRIOR_CI_SEQUENCE_NUMBER = SEQUENCE_NUMBER, allowing a period with no predecessor to still be returned with null prior-period columns. The inclusion of the _ALL suffix indicates the underlying table participates in the EBS multi-organization model; consumers should be aware that the view itself does not carry an ORG_ID predicate, so callers must apply any required operating-unit or business-group filtering when the underlying data is partitioned.

Key Columns

  • CAL_TYPE — Calendar type identifier; the primary grouping key for periods.
  • SEQUENCE_NUMBER — Ordering sequence of the period within the calendar type.
  • START_DT / END_DT — Period start and end dates.
  • CAL_STATUS — Status code of the period, joined to IGS_CA_STAT.
  • ALTERNATE_CODE — External/alternate identifier for the period (IN1), distinct from the prior period's alternate code in IN2.
  • SS_DISPLAYED — Self-service display indicator.
  • IVR_DISPLAY_IND — Interactive Voice Response display indicator; governs telephony-channel visibility of the period.
  • SUP_CAL_STATUS_DIFFER_IND — Flags whether the supplemental calendar status differs from the primary status.
  • DESCRIPTION — Period description (IN1); the result set also exposes the calendar type description (TY3) and status description (ST4).
  • PRIOR_CI_SEQUENCE_NUMBER — Pointer to the preceding period, supporting chronological traversal.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — Standard EBS audit columns.

Common Use Cases and Queries

Typical uses include populating academic calendar pick lists, driving enrollment and registration windows, feeding IVR/self-service channels, and performing chronological gap analysis across periods.

  • List IVR-enabled periods for a calendar type:
SELECT cal_type, sequence_number, start_dt, end_dt, description
FROM   apps.igsfv_calendar_periods
WHERE  cal_type = :p_cal_type
AND    ivr_display_ind = 'Y'
ORDER  BY sequence_number;
  • Return each period with its predecessor's dates:
SELECT cal_type, sequence_number, start_dt, end_dt,
       prior_ci_sequence_number
FROM   apps.igsfv_calendar_periods
WHERE  cal_type = :p_cal_type
ORDER  BY sequence_number;

Because the view is read-only and references only these four objects, it performs efficiently when filtered by CAL_TYPE, which is indexed on the underlying instance table. For high-volume extracts, restrict the query by date range on START_DT/END_DT and avoid functions on indexed predicates.