Search Results igs_ad_rel_con_int_u1

Overview

IGS_AD_REL_CON_INT_ALL is an interface (staging) table in the Oracle E-Business Suite Student System (IGS) product family. It holds a person's relative contact details as received through an external data load, prior to validation and transfer into the production contact-point structures. The table exists to decouple inbound feeder data — prospect, applicant, or student relative information originating from external systems, self-service pages, or bulk imports — from the live relational model, allowing the concurrent program that processes the interface to validate, match, and reject rows without touching transactional data.

Consistent with the _INT_ALL naming convention, the table is multi-organization aware: it carries an ORG_ID column and is therefore partitioned by operating unit or business group through the standard EBS Multiple Organization Access Control (MOAC) mechanism. Rows are written by the feeder process, stamped with interface run and concurrent request identifiers, and consumed by the relative-contact import concurrent program. Upon successful processing, the interface row typically drives creation of an HZ_CONTACT_POINTS record for the related person and is then either purged or flagged.

From a Data Vault modeling perspective, the documented foreign-key profile suggests this object behaves satellite-leaning: it carries descriptive contact attributes attached to a parent relative relationship, plus a link back to the contact-point hub. It is best modeled as a satellite hanging off the IGS_AD_RELATIONS_INT_ALL relationship, rather than as an independent hub.

Key Information Stored

The table contains 26 documented columns. The most significant are:

• INTERFACE_REL_CON_ID — the surrogate primary key, enforced by unique index IGS_AD_REL_CON_INT_U1. It uniquely identifies each staged relative contact row and serves as the reference used by downstream processing and error logging.
• INTERFACE_RELATIONS_ID — foreign key to IGS_AD_RELATIONS_INT_ALL; this is the business link that ties the contact detail to its parent staged relative relationship. It is the principal join key during import.
• ORG_ID — the operating unit or business group owner, driving MOAC security and partitioning of the interface data.
• CONTACT_POINT_TYPE and PRIMARY_FLAG — classify the contact (for example e-mail versus phone) and identify the preferred contact for the relative.
• EMAIL_ADDRRESS, EMAIL_FORMAT — the staged e-mail address and its format indicator (note the documented spelling of the address column).
• PHONE_LINE_TYPE, PHONE_COUNTRY_CODE, PHONE_AREA_CODE, PHONE_NUMBER, PHONE_EXTENSION — the decomposed telephone attributes mirrored from the HZ contact-point model.
• STATUS, MATCH_IND, ERROR_CODE — processing state, match outcome against existing contact points, and the rejection reason when validation fails.
• DUP_CONTACT_POINT_ID — foreign key to HZ_CONTACT_POINTS, populated when the row matches or duplicates an existing contact point.
• DUP_CONTACT_POINT_ID plus the standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and concurrent-program columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, INTERFACE_RUN_ID) — provide auditability and traceability back to the originating request.

Common Use Cases and Queries

Typical scenarios include monitoring interface backlog, diagnosing rejected rows, and reconciling loaded contacts. A representative pattern selects unprocessed rows for a given run:

• SELECT interface_rel_con_id, interface_relations_id, contact_point_type, status, error_code FROM igs_ad_rel_con_int_all WHERE interface_run_id = :run_id AND status = 'E';
• Joining to the parent relationship to inspect a full staged record: ... FROM igs_ad_rel_con_int_all c, igs_ad_relations_int_all r WHERE c.interface_relations_id = r.interface_relations_id AND c.org_id = :org_id;
• Confirming match outcomes against live contact points: ... JOIN hz_contact_points h ON c.dup_contact_point_id = h.contact_point_id;
• Reporting counts by contact type, status, and error code for a load cycle, and identifying rows with a PRIMARY_FLAG set where duplicates exist.

Because the table is an interface object, reporting should generally target the post-import production tables; IGS_AD_REL_CON_INT_ALL is best used for operational monitoring and error triage.

Related Objects

• IGS_AD_RELATIONS_INT_ALL — parent interface table; joined via INTERFACE_RELATIONS_ID. Consumed together by the relative import program.
• HZ_CONTACT_POINTS — target registry reference; joined via DUP_CONTACT_POINT_ID and populated on successful load.
• HZ_CONTACT_POINT_TYPES / contact-point setup views — supply validation for CONTACT_POINT_TYPE.
• FND_CONCURRENT_REQUESTS / FND_CONCURRENT_PROGRAMS
• HZ_PARTIES and related party/relationship registries — the eventual destinations of the staged relative and contact data.

Documentation for this table is limited; specific import APIs and purge logic should be confirmed against the IGS Student System implementation guides for the target release (12.1.1 or 12.2.2).