Results for “adm_offer_resp_status_desc”

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

Overview

The view IGS_UC_MAP_OFF_RESP_V belongs to the IGS (Student System) product family, which is documented as obsolete within Oracle E-Business Suite 12.1.1 and 12.2.2. In EBS terms, an obsolete product is one that is no longer actively maintained, though its database objects may persist for backward compatibility in environments where the module was previously licensed or seeded. This view presents the mapping between inbound UCAS (Universities and Colleges Admissions Service) decision and reply codes and the corresponding Oracle Student System (OSS) admissions offer response status codes, together with their descriptive text.

Functionally, the view is a reference-lookup construct. UCAS communicates admissions decisions and applicant replies using its own coded values, while Oracle Student System records admissions offer responses using internal status codes. IGS_UC_MAP_OFF_RESP_V resolves both sides into human-readable descriptions, allowing institutions that imported UCAS data into OSS to reconcile decision/reply combinations against the resulting offer response status. It serves reporting and validation purposes rather than transactional ones.

Underlying Base Objects

The ETRM metadata documents no referenced base objects, and the object is recorded as not implemented in the reference database. However, the documented view text reveals four underlying objects used in its definition:

• IGS_UC_MAP_OFF_RESP (aliased MOR) — the driving mapping table holding system code, decision code, reply code, admissions offer response status, and the closed indicator.
• IGS_LOOKUP_VALUES (aliased LK1) — joined on lookup type IGS_UC_APP_DECISION and the row's decision code, supplying the decision description.
• IGS_LOOKUP_VALUES (aliased LK2) — joined on lookup type IGS_UC_APP_REPLY and the row's reply code, supplying the reply description.
• IGS_AD_OFR_RESP_STAT (aliased OFR) — joined on admissions offer response status, supplying the status description.

The view is therefore an inner-join consolidation: rows are returned only where the mapping table row resolves against all three lookup sources.

Key Columns

• ROW_ID — the ROWID of the base mapping row, exposed as the view's row identifier.
• SYSTEM_CODE — identifies the originating system for the mapping.
• DECISION_CODE / DECISION_DESC — the UCAS decision code and its resolved meaning from the IGS_UC_APP_DECISION lookup.
• REPLY_CODE / REPLY_DESC — the UCAS reply code and its resolved meaning from the IGS_UC_APP_REPLY lookup. REPLY_DESC is the column most frequently targeted by ad hoc queries against this view.
• ADM_OFFER_RESP_STATUS / ADM_OFFER_RESP_STATUS_DESC — the internal OSS offer response status and its description from IGS_AD_OFR_RESP_STAT.
• CLOSED_IND — indicates whether the mapping entry is inactive or closed.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit columns inherited from the mapping table.

Common Use Cases and Queries

Typical usage involves verifying that imported UCAS decision/reply pairs map to the expected OSS offer response status, and producing reconciliation reports with descriptive labels. The following examples illustrate common access patterns.

• Listing all active mappings with descriptions:

  SELECT decision_code, decision_desc, reply_code, reply_desc,
         adm_offer_resp_status, adm_offer_resp_status_desc
  FROM   igs_uc_map_off_resp_v
  WHERE  closed_ind = 'N';

• Searching by reply description, reflecting the "reply_desc" search term:

  SELECT decision_code, reply_code, reply_desc,
         adm_offer_resp_status_desc
  FROM   igs_uc_map_off_resp_v
  WHERE  UPPER(reply_desc) LIKE '%ACCEPT%';

• Resolving a specific decision/reply combination to its OSS status:

  SELECT adm_offer_resp_status, adm_offer_resp_status_desc
  FROM   igs_uc_map_off_resp_v
  WHERE  decision_code = :decision_code
  AND    reply_code    = :reply_code;

Because the module is obsolete, implementations should confirm object availability before relying on this view in new reports.