Results for “interface_relemp_id”

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

Overview

IGS_AD_RELEMP_INT_ALL is an interface (staging) table within the Oracle E-Business Suite IGS – Student System product. It holds inbound data describing the employment details of a person's relatives, staged for validation and subsequent transfer into the base Student System tables. As part of the admissions and student records area, the table supports the collection of sibling, parent, or guardian employment information supplied during application processing, typically imported in batch from external sources or legacy systems before being reconciled against the permanent relations and employment entities.

The table is documented under product IGS – Student System and is marked Obsolete; the ETRM metadata confirms it is "not implemented in this database" for the reference environment. In release 12.1.1 the object is owned by the IGS schema and carries 35 documented columns. Its structure is characteristic of an EBS open-interface table: surrogate sequence-driven identifier, descriptive business attributes, and a standard concurrency and audit column set (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) plus request/interface control columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, INTERFACE_RUN_ID).

Following the heuristic Data Vault classification supplied in the metadata, the object models as a standalone structure — effectively a raw staging satellite rather than a resolved hub or link. It captures descriptive employment context that will resolve to a person/relative hub and an employment-fact link once the interface run completes and the data is validated.

Key Information Stored

The single-column primary key, IGS_AD_RELEMP_INT_U1, is defined on INTERFACE_RELEMP_ID, the surrogate identifier for each staged employment row. The most significant columns are:

• INTERFACE_RELEMP_ID — surrogate primary key, uniquely identifying each interface employment record.
• INTERFACE_RELATIONS_ID — foreign key to IGS_AD_RELATIONS_INT_ALL, linking the employment record to its parent relative record.
• ORG_ID — operating unit / multi-org partition key, essential for any org-secured query.
• CONTACT, EMPLOYER, EMPLOYED_BY_DIVISION_NAME, BRANCH — the employer identity and contact details.
• START_DT, END_DT — employment period; used to derive duration and current employment status.
• TYPE_OF_EMPLOYMENT, FRACTION_OF_EMPLOYMENT, TENURE_OF_EMPLOYMENT, WEEKLY_WORK_HOURS — quantitative employment characteristics.
• POSITION, OCCUPATIONAL_TITLE_CODE, MILITARY_RANK — job title and classification data.
• MATCH_IND, STATUS, ERROR_CODE — interface processing control; MATCH_IND flags reconciliation status, STATUS tracks record state, ERROR_CODE carries validation failures.
• DUP_EMPLOYMENT_HISTORY_ID — reference retained for duplicate-history resolution.
• INTERFACE_RUN_ID, REQUEST_ID — correlate each row back to the concurrent request and interface run that loaded it.

Business-key candidates are not separately enumerated as a unique index in the metadata; the only documented unique constraint is the surrogate primary key. Natural identification of a relative's employment row therefore depends on the composite of INTERFACE_RELATIONS_ID and the employment attributes.

Common Use Cases and Queries

Typical usage centres on monitoring and troubleshooting inbound interface loads. Analysts query rows by STATUS or ERROR_CODE to identify records that failed validation, and group by INTERFACE_RUN_ID to reconcile counts against the source extract.

A representative diagnostic query:

SELECT interface_relemp_id, interface_relations_id, employer, position, start_dt, end_dt, status, error_code, request_id FROM igs_ad_relemp_int_all WHERE status IS NULL OR error_code IS NOT NULL AND org_id = :p_org_id;

Downstream reconciliation before purge commonly joins back to the parent relations interface on the documented foreign key:

SELECT r.interface_relations_id, e.employer, e.type_of_employment FROM igs_ad_relemp_int_all e, igs_ad_relations_int_all r WHERE e.interface_relations_id = r.interface_relations_id AND e.interface_run_id = :p_run_id;

Reporting scenarios include producing relative-employment summaries for admissions review, verifying that all expected relations have at least one employment row, and auditing interface throughput by request and program. Because the object is obsolete and not implemented in the reference database, these patterns are relevant chiefly to legacy environments and migration archaeology.

Related Objects

The documented relationship data identifies one explicit foreign key, and the surrounding IGS interface family provides the remaining dependencies:

• IGS_AD_RELATIONS_INT_ALL — parent interface table; joined via INTERFACE_RELEMP_INT_ALL.INTERFACE_RELATIONS_ID = IGS_AD_RELATIONS_INT_ALL.INTERFACE_RELATIONS_ID.
• IGS_AD_RELATIONS (base table) — permanent relative records to which validated relation interfaces are transferred.
• IGS_AD_RELEMP (base table) — the corresponding permanent relative-employment entity that receives validated rows.
• IGS_AD_INTERFACE_RUNS — the interface run control entity referenced by INTERFACE_RUN_ID.
• FND_CONCURRENT_REQUESTS — resolves REQUEST_ID to the concurrent program that executed the load.
• FND_PROGRAM / FND_APPLICATION — resolve PROGRAM_ID and PROGRAM_APPLICATION_ID to the loading program.

No additional foreign keys are documented for this object, consistent with its standalone staging classification.