Search Results igf_sl_reqd_fields_pk

Overview

IGF_SL_REQD_FIELDS is a configuration and validation-support table within the Oracle E-Business Suite Financial Aid (IGF) module. It stores the set of fields that are required or mandatory for processing a student loan, and is referenced during the validation phase that verifies each field submitted to an external loan processor actually carries a value. Because the module is marked obsolete in the reference documentation, the object is primarily relevant to legacy implementations, historical data migrations, and upgrade impact analysis between EBS 12.1.1 and 12.2.2. The documentation for this database records that the object is "not implemented," meaning it is catalogued in the ETRM repository but does not exist as a deployed physical segment in the given instance.

From a heuristic Data Vault modeling perspective, IGF_SL_REQD_FIELDS is classified as a standalone structure, meaning the mined foreign-key footprint identifies no parent or child links. It behaves as a reference or lookup satellite: each row describes one required-field rule keyed by a specification version and a set of loan attributes, rather than recording a transactional event or a business entity in its own right.

Key Information Stored

The table carries twelve documented columns. The most consequential are listed below.

• LRF_ID — the surrogate primary key column, enforced by the constraint IGF_SL_REQD_FIELDS_PK and by unique index IGF_SL_REQD_FIELDS_U1. This is the value a user searching for igf_sl_reqd_fields_pk is typically retrieving.
• SPEC_VERSION — the specification version the rule applies to, allowing multiple generations of validation rules to coexist.
• FIELD_NAME — the identifier of the field whose presence is being enforced.
• LOAN_TYPE — the loan category to which the requirement applies.
• TRANSACTION_TYPE — the loan transaction context that scopes the rule.
• PRC_TYPE_CODE — the processing type code that further qualifies when the requirement is evaluated.
• STATUS — the enabled/disabled indicator controlling whether the rule is active.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS audit columns maintained by the WHO columns convention.

Two unique indexes are documented. IGF_SL_REQD_FIELDS_U1 enforces uniqueness on LRF_ID alone, effectively duplicating the primary key. IGF_SL_REQD_FIELDS_U2 is the meaningful business-key candidate, combining SPEC_VERSION, FIELD_NAME, LOAN_TYPE, TRANSACTION_TYPE, and PRC_TYPE_CODE. That composite guarantees a single requirement row per specification, field, and processing context, which is precisely the grain a validation engine would look up at run time.

Common Use Cases and Queries

The dominant use case is diagnosing why a loan record failed validation before transmission to an external processor. A support or data analyst resolves the complaint by joining the applicant's loan attributes against the rule set. A representative pattern follows, filtering on the business key rather than the surrogate:

• Retrieve the rule row behind a constraint error: SELECT * FROM igf.igf_sl_reqd_fields WHERE spec_version = :p_version AND field_name = :p_field AND status = 'A';
• Resolve an unknown surrogate key reported in an error message: SELECT * FROM igf.igf_sl_reqd_fields WHERE lrf_id = :p_lrf_id;
• Enumerate all mandatory fields for a given loan and transaction combination, ordered for documentation: SELECT field_name FROM igf.igf_sl_reqd_fields WHERE loan_type = :p_loan AND transaction_type = :p_trx AND prc_type_code = :p_prc AND status = 'A';
• Audit rule churn, using the WHO columns: SELECT field_name, last_updated_by, last_update_date FROM igf.igf_sl_reqd_fields WHERE spec_version = :p_version ORDER BY last_update_date DESC;

Reporting use cases include producing a requirements matrix per specification version for compliance review, comparing active rule counts across loan types after a configuration change, and extracting the full rule set for migration into a successor system.

Related Objects

The ETRM relationship mining returns a standalone Data Vault classification, so no enforced foreign keys are documented. The functional coupling is therefore implicit and driven by shared code values rather than constraints. The principal objects that reference or depend on this table are:

• IGF_SL_LOANS — the loan record whose field values are tested against these requirements.
• IGF_SL_LOAN_APPLICATIONS — supplies the applicant-level attributes validated during processing.
• IGF_SL_REQD_FIELD_VALUES — the value-side counterpart, where applicable, pairing stored values with the required fields.
• IGF_SL_PROCESSING — the outbound processing run that triggers validation.
• IGF_SL_SPEC_VERSIONS — the specification version master joined on SPEC_VERSION.
• IGF_LOOKUPS — the lookup source that resolves LOAN_TYPE, TRANSACTION_TYPE, and PRC_TYPE_CODE into display meanings.
• FND_USER — resolves CREATED_BY and LAST_UPDATED_BY to operator names for audit reporting.

Because the object is obsolete and absent from the deployed schema, consultants should confirm its existence in each target instance before writing dependent SQL, and should treat any surviving rows as historical configuration requiring manual interpretation.