Search Results inquiry_source_type




Overview

IGS.IGR_I_LINES_INT is the inquiry-lines interface table in the Oracle E-Business Suite Student System / Oracle iRecruitment product family (IGS schema). It serves as the staging area for academic interest records (inquiry lines) that are loaded through the Inquiry Import concurrent program before they are validated and transferred into the production table IGR_I_A_LINES. Rows in this interface table represent the line-level detail of an inquiry application and are always associated with a parent row in IGS.IGR_I_APPL_INT.

The table resides in the APPS_TS_INTERFACE tablespace, which is standard for EBS open-interface tables, and its lifecycle status is active. From a Data Vault modeling perspective, the FK-derived link classification suggests that IGR_I_LINES_INT functions as a link table: it connects a specific inquiry application (INTERFACE_INQ_APPL_ID) to a set of academic interest attributes such as program preference, sales lead, product category, and inquiry source type. This link classification should be treated as a heuristic modeling suggestion rather than a definitive EBS design classification, since the table also carries descriptive satellite-type attributes (status, error codes, match indicators) that are typical of interface staging structures.

Key Information Stored

The table is keyed by the surrogate primary key INTERFACE_LINES_ID (NUMBER(15)), populated from a sequence, and enforced uniquely through index IGR_I_LINES_INT_PK. The primary business-key candidate identified in the metadata is the same INTERFACE_LINES_ID index, since the inquiry application number and other natural keys are not guaranteed unique at the line level.

Standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and concurrent-program audit columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE) are also present.

Common Use Cases and Queries

The most common operational use is monitoring the concurrent import and diagnosing failed rows. A typical diagnostic query filters on STATUS and surfaces error text:

SELECT l.interface_lines_id, l.interface_inq_appl_id, l.inquiry_source_type,
       l.status, l.error_code, l.error_text
 FROM igs.igr_i_lines_int l
 WHERE l.interface_run_id = :run_id
   AND l.status = 'ERROR';

For inquiry-source analytics, developers join the interface rows to the parent application and count by channel before or after import:

SELECT inquiry_source_type, COUNT(*)
 FROM igs.igr_i_lines_int
 WHERE interface_run_id = :run_id
 GROUP BY inquiry_source_type;

Reconciliation queries match staged rows to production IGR_I_A_LINES using MATCH_IND and INTERFACE_LINES_ID. Reports on sales-lead conversion join through SALES_LEAD_ID to AS_SALES_LEADS. Bulk cleanup of a rejected run is performed by deleting on INTERFACE_RUN_ID and STATUS.

Related Objects

  • IGS.IGR_I_APPL_INT – Parent interface table joined via INTERFACE_INQ_APPL_ID.
  • IGS.IGR_I_A_LINES – Production destination table for validated rows.
  • AS.AS_SALES_LEADS – Referenced through SALES_LEAD_ID.
  • MTL_CATEGORIES_B / MTL_CATEGORY_SETS_B – Referenced through PRODUCT_CATEGORY_ID and PRODUCT_CATEGORY_SET_ID.
  • FV.FV_DMS_CODE_DEFINITIONS_ALL – Referenced through PROGRAM_CODE_ID for program code lookups.
  • Concurrent programs – The Inquiry Import program reads and updates rows via INTERFACE_RUN_ID, REQUEST_ID, and PROGRAM_ID.