Search Results edtr_id




Overview
Explore in AI Chat

Overview

IGF_SL_EDIT_REPORT is an APPS-owned, VALID database view within the IGF (Financial Aid) product family of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2 release levels. The view exposes student loan edit report data captured during loan processing and validation cycles, presenting row-level details of errors and edits detected against individual loans. It is a reporting and inquiry construct rather than a transactional base table; it does not store data itself but projects columns from its underlying base object in a form intended for direct query access by both end users and programmatic consumers.

Because the view includes multi-org filter logic keyed on the ORG_ID column and the CLIENT_INFO session context, it behaves as an operating-unit (ORG_ID) secured query. Each query automatically restricts returned rows to the organization established by the session context, or to rows matching the default sentinel value of -99 when no org context is supplied. This makes it suitable for concurrent program output, custom reports, and integration extracts that must remain organization-aware without additional filtering by the developer.

Underlying Base Objects

The view is defined over a single documented base object, IGF_SL_EDIT_REPORT_ALL, aliased as EDTR in the view text. Although the ETRM metadata lists no additional referenced objects, the naming convention of the base table (_ALL) confirms that it is the multi-org enabled repository of student loan edit report rows from which the view derives its ORG_ID column. The view is a straightforward projection: it selects a fixed set of columns from IGF_SL_EDIT_REPORT_ALL with no joins, unions, or aggregations, applying only the NVL/DECODE-based organization predicate in the WHERE clause. Consequently, one row in the base table corresponds to exactly one row in the view, and no duplication or row multiplication occurs. The view does not perform any transformation of the error type, error code, or field-level attributes; those values are passed through verbatim.

Key Columns

  • ROW_ID — the ROWID of the underlying EDTR row, providing a direct physical identifier for the record.
  • EDTR_ID — surrogate primary identifier for the edit report entry.
  • LOAN_NUMBER — the loan against which the edit or error was detected.
  • ORIG_CHG_CODE — the originating change code associated with the edit record.
  • SL_ERROR_TYPE — classification of the error raised by the student loan validation logic.
  • SL_ERROR_CODE — the specific student loan error code, the attribute most frequently used to filter, group, and diagnose validation outcomes. This is the column commonly targeted when users search for "sl_error_code" in the context of student loan edit reporting.
  • FIELD_NAME and FIELD_VALUE — the particular field that failed validation and the value that triggered the error, enabling row-level diagnosis.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.
  • REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context, identifying the process that generated the record.
  • ORG_ID — operating unit identifier, driving the multi-org filter in the view definition.

Common Use Cases and Queries

Typical usage includes reconciling loan edit outcomes, isolating records for a specific error code, and feeding downstream extracts. Because the view is org-secured, queries benefit from setting the client info context or accepting the default behavior. For example, to inspect a specific error code across the session organization:

  • SELECT loan_number, sl_error_type, sl_error_code, field_name, field_value FROM apps.igf_sl_edit_report WHERE sl_error_code = :p_error_code ORDER BY loan_number;
  • SELECT sl_error_code, COUNT(*) FROM apps.igf_sl_edit_report GROUP BY sl_error_code ORDER BY 2 DESC;
  • SELECT request_id, loan_number, sl_error_code FROM apps.igf_sl_edit_report WHERE request_id = :p_request_id;

These patterns support error triage, concurrent program validation, and audit reporting, relying on the view's pass-through semantics and organization predicate rather than any computed logic of its own.