Results for “igr_i_a_lines”

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

Overview

IGR_I_A_LINES is a junction table within the IGS (Student System) product schema of Oracle E-Business Suite, documented as VALID in both 12.1.1 and 12.2.2 environments. Its described purpose is to serve as the junction table for the Sales Lead Line table, meaning it resolves a many-to-many relationship between individual parties (prospects or enquiries) and the sales lead lines recorded against them. As a junction, or intersection, entity it enables a single sales lead line to be associated with multiple enquiry or application contexts, and conversely allows a person to be linked to multiple lead lines over time without duplicating either master record.

Because the table carries its own descriptive attribute, PREFERENCE, alongside its foreign key columns, it functions as more than a pure cross-reference. From a Data Vault modeling perspective, the metadata's heuristic classification is link. This is a reasonable modeling suggestion: IGR_I_A_LINES sits between the HZ_PARTIES hub (represented by PERSON_ID) and the AS_SALES_LEAD_LINES hub (represented by SALES_LEAD_LINE_ID), with ENQUIRY_APPL_NUMBER completing the composite relationship key. Teams building an analytical or integration layer can treat it as a link table whose non-key attributes may warrant a satellite if historical change tracking is required.

Key Information Stored

The documented physical schema contains thirteen columns in release 12.1.1. The columns of greatest functional significance are:

• PERSON_ID — Foreign key to HZ_PARTIES, identifying the party (prospect, applicant, or student) associated with the lead line. This is a business-key component and part of the composite primary key.
• ENQUIRY_APPL_NUMBER — Identifies the enquiry or application that provides the recruitment context for the association. Also a business-key component of the composite primary key.
• SALES_LEAD_LINE_ID — Foreign key to AS_SALES_LEAD_LINES, identifying the specific lead line being linked.
• PREFERENCE — A descriptive attribute capturing ordering or preference information for the association, and the only non-key business attribute documented beyond audit columns.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide standard row-level auditability.
• Concurrent program columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE record the concurrent manager context that last touched the row.

The surrogate-style uniqueness is expressed through the composite primary key IGR_I_A_LINES_PK, defined across PERSON_ID, ENQUIRY_APPL_NUMBER, and SALES_LEAD_LINE_ID. There is no single surrogate identifier column; the primary key is a natural composite business key, so uniqueness is enforced at the combination of party, enquiry/application, and lead line.

Common Use Cases and Queries

Typical usage centres on recruitment and admissions reporting: tracing which prospects are attached to which sales lead lines, and aggregating enquiry or application activity per party. A representative join pattern is:

• Join IGR_I_A_LINES to HZ_PARTIES on PERSON_ID = PARTY_ID to resolve party names and contact details for a lead line.
• Join IGR_I_A_LINES to AS_SALES_LEAD_LINES on SALES_LEAD_LINE_ID to obtain lead line descriptions, status, and owning organisations.
• Filter by ENQUIRY_APPL_NUMBER to isolate all lead lines and parties tied to a specific enquiry or application.

A simple diagnostic query counts associated lines per person: SELECT PERSON_ID, COUNT(*) FROM IGS.IGR_I_A_LINES GROUP BY PERSON_ID; Reporting extracts frequently combine the three key columns with PREFERENCE to present ordered lead line associations. Because the table is an intersection, de-duplication checks and orphan analysis should always be performed against both parent tables before data migration or interface loading.

Related Objects

The most significant objects related to IGR_I_A_LINES are the two tables referenced by its foreign keys and the surrounding IGS recruitment entities:

• HZ_PARTIES — referenced via IGR_I_A_LINES.PERSON_ID; the master party record for the individual.
• AS_SALES_LEAD_LINES — referenced via IGR_I_A_LINES.SALES_LEAD_LINE_ID; the lead line master detail.
• IGR_I_A_LINES_PK — the composite primary key constraint enforcing uniqueness on PERSON_ID, ENQUIRY_APPL_NUMBER, and SALES_LEAD_LINE_ID.
• AS_SALES_LEAD_HEADERS — the header entity above the lines, relevant when reporting at lead level.
• IGS enquiry and application tables — the enquiry/application entities implicitly referenced by ENQUIRY_APPL_NUMBER, which should be joined when translating that number into applicant context.

Writers and integrations should observe the foreign key dependencies to HZ_PARTIES and AS_SALES_LEAD_LINES, since both parent rows must exist before an association can be inserted.