Results for “igr_i_appl”

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

Overview

The IGR_I_APPL view is a reporting and integration object owned by the APPS schema in Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2. It belongs to the IGS – Student System product family, which provides the recruiting and admissions foundation for higher-education institutions. The view presents a flattened, denormalized record of applicant or enquiry data, combining the IGS-specific application attributes with lead information maintained in Oracle Marketing (OMO). It is documented as a VALID view in the ETRM repository.

The explicit purpose stated in the documentation is to expose only the attributes required by OSS (Oracle Student System / Student Information). It is therefore a purpose-built projection rather than a full mirror of its source tables. This design reduces the surface area available to consuming components, decoupling them from internal column changes in the underlying IGS and OMO tables. Because it sits at the boundary between the recruiting (lead) domain and the admissions (application) domain, it plays an important integration role, allowing downstream code to read enquiry and lead status alongside application reference keys in a single query.

Underlying Base Objects

The view is defined over two documented sources:

• IGR_I_APPL_ALL — a junction (intersection) table in the IGS schema that stores the association between a sales lead and an application or enquiry, keyed by SALES_LEAD_ID. This supplies the IGS application-specific attributes, calendar references, and the descriptive flexfield (DFF) segments.
• AS_SALES_LEADS_V — the public OMO view over sales leads, which supplies lead status, enquiry method, and audit information.

The two objects are joined on SALES_LEAD_ID. Additionally, the view definition references an ORG_ID predicate built with NVL, TO_NUMBER, and DECODE against a substitution value (truncated in the sourced text), which enforces multi-org or operating-unit security filtering. The ETRM 12.2.2 metadata lists no additional documented base objects, so the two sources above are authoritative.

Key Columns

• ROW_ID — the ROWID of the IGR_I_APPL_ALL row, useful for identifying a specific junction record.
• SALES_LEAD_ID — the join key linking application data to the OMO lead.
• PERSON_ID and PARTY_ID — the person and trading-party identifiers for the enquirer or applicant.
• ENQUIRY_APPL_NUMBER — the enquiry/application reference number.
• ACAD_CAL_TYPE, ACAD_CI_SEQUENCE_NUMBER, ADM_CAL_TYPE, ADM_CI_SEQUENCE_NUMBER — academic and admissions calendar type and sequence references.
• ENQUIRY_DT, INDICATED_MAILING_DT, LAST_PROCESS_DT — key dates for enquiry, correspondence, and processing.
• INQUIRY_METHOD_CODE, INQUIRY_METHOD, DSP_DESCRIPTION, DSP_CLOSED_IND — lead response/method codes and descriptions derived from the OMO view.
• ENQUIRY_STATUS, S_ENQUIRY_STATUS, ENABLED_FLAG — lead status and enabled indicator.
• REGISTERING_PERSON_ID, OVERRIDE_PROCESS_IND, PKG_REDUCT_IND — registration and process-control attributes.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE20 — the descriptive flexfield segments.
• ORG_ID — the operating unit, essential for multi-org filtering.
• OMS audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN (from the lead source).
• Concurrent request columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE.

Common Use Cases and Queries

Typical uses include applicant enquiry reporting, lead-to-application conversion analysis, and integration feeds consumed by student-system components. A basic listing:

• SELECT ENQUIRY_APPL_NUMBER, PERSON_ID, ENQUIRY_STATUS, ENQUIRY_DT FROM APPS.IGR_I_APPL WHERE ORG_ID = :p_org_id;
• Filtering by enquiry method: WHERE INQUIRY_METHOD_CODE = :p_method.
• Joining to person or lead tables on PERSON_ID or SALES_LEAD_ID for detail enrichment.
• Trending inbound enquiries by ENQUIRY_DT and ACAD_CAL_TYPE.

Because ORG_ID filtering is embedded via the multi-org predicate, consumers should supply the operating unit through the standard EBS multi-org initialization (for example FND_GLOBAL.ORG_ID) to return the correct data set.