Results for “igs_ad_interface_all”

50+ results




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

Overview

The IGS_AD_INTERFACE_ALL table belongs to the IGS (Student System) product family within Oracle E-Business Suite. Its documented purpose is to hold an individual's import data received from different sources, functioning as a staging and interface table through which person records are loaded into the institution's student system before being validated and promoted to the master person registry. The table carries a documented physical schema in ETRM 12.1.1 with 67 columns under the IGS schema, and the same object definition is catalogued for 12.1.1 and 12.2.2. Note that the product is flagged as obsolete, and the metadata records "Not implemented in this database" for implementation/DBA data, meaning the table may be absent or dormant in a given instance depending on which Student System modules were licensed and installed.

From a modeling perspective, the heuristic Data Vault classification derived from the foreign key structure is hub-leaning. The table centers on a single surrogate identifier (INTERFACE_ID) and anchors relationships to person and application entities, which suggests it is best treated as a hub-like entity for the interface batch rather than as a pure transactional satellite, even though it also carries a large volume of descriptive, record-level attributes.

Key Information Stored

The primary key is IGS_AD_INTERFACE_PK, defined on INTERFACE_ID, which is the surrogate key for each imported person record. Business-key candidates include PERSON_NUMBER and PREF_ALTERNATE_ID, which typically identify a person externally, while PERSON_ID is a resolved reference to the master party record once matching completes. The most significant columns include:

Common Use Cases and Queries

The table is primarily queried during interface monitoring and error reconciliation. A typical pattern selects rows pending or failed processing for a given batch:

  • Identify unmatched records: SELECT INTERFACE_ID, PERSON_NUMBER, SURNAME, GIVEN_NAMES, MATCH_IND, ERROR_CODE FROM IGS_AD_INTERFACE_ALL WHERE BATCH_ID = :p_batch AND MATCH_IND = 'N';
  • Reconcile a load run: SELECT INTERFACE_RUN_ID, RECORD_STATUS, COUNT(*) FROM IGS_AD_INTERFACE_ALL GROUP BY INTERFACE_RUN_ID, RECORD_STATUS;
  • Trace a person back to source: join on PERSON_ID to HZ_PARTIES to compare staged demographics against the master record.
  • Audit staging provenance using REQUEST_ID against FND_CONCURRENT_REQUESTS to identify the concurrent program that created the rows.

Related Objects

The documented relationships connect the interface rows to master person and downstream application data:

  • HZ_PARTIES – joined via IGS_AD_INTERFACE_ALL.PERSON_ID to resolve the imported person to the Trading Community party.
  • IGS_AD_APL_INT – references IGS_AD_INTERFACE_ALL via INTERFACE_ID, carrying admission application interface data tied to the same import.
  • IGS_PE_RES_DTLS_INT – references IGS_AD_INTERFACE_ALL via INTERFACE_ID (documented twice), holding residence detail interface rows associated with the import.

These relationships confirm that IGS_AD_INTERFACE_ALL acts as the parent interface entity for person, application, and residence staging data within the Student System.