Search Results igf_sl_cr_resp_dtls




Overview
Explore in AI Chat

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

Overview

The IGF_SL_CR_RESP_DTLS table is owned by the IGF schema and belongs to the Financial Aid product family within Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to store the Common Record Tag Response Elements extracted from inbound response XML files exchanged with student loan servicing entities. The Common Record is the standardized data structure used for federal Title IV loan processing, and this table serves as the persistence layer for the response-side tag values that originate from those external messages.

Under the heuristic Data Vault classification derived from the foreign-key structure, this table is assessed as hub-leaning. In Data Vault modeling terms, that suggests the table primarily functions as a hub anchored by a single business key, with dependent attributes and downstream relationships modeled separately. Modelers may therefore treat DOCUMENT_ID_TXT as the stable business key and separate transactional detail accordingly, while still respecting the physical schema as delivered.

Key Information Stored

The documented physical schema contains twenty columns, with the surrogate primary key defined by the unique index IGF_SL_CR_RESP_DTLS_PK on DOCUMENT_ID_TXT. This column is both the primary key and the business-key candidate, meaning it uniquely identifies each response document. The most significant columns include:

  • DOCUMENT_ID_TXT — unique identifier of the Common Record response document; the primary/business key.
  • DOC_CREATED_DATE — the date the originating response document was created.
  • SOURCE_ENTITY_ID_TXT — identifier of the sending entity (typically the servicer or servicer provider).
  • DEST_ENTITY_ID_TXT — identifier of the receiving entity (the institution or its agent).
  • SOFT_PROVIDER and SOFT_VERSION — the software provider and version that produced the response, used for interoperability diagnostics.
  • FULL_RESP_CODE — the full response code returned for the document, indicating success or the nature of a processing outcome.
  • RECEIPT_DATE — the date the response was received into the system.
  • DOC_TYPE_CODE and DOC_STATUS_CODE — the document type and current status of the response.
  • PROCESS_DATE — the date the document was processed by the EBS process.
  • LAST_UPDATE_DATE — standard WHO audit column tracking the most recent modification.

The remaining columns are standard Oracle EBS WHO audit and concurrent manager columns, including CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, and REQUEST_ID. These support traceability back to the concurrent program execution that inserted or updated the row.

Common Use Cases and Queries

Typical usage centers on reconciling inbound servicer responses against outbound requests, auditing processing failures, and reporting on document status.

  • Retrieving responses for a specific document or entity range: SELECT document_id_txt, full_resp_code, doc_status_code FROM igf_sl_cr_resp_dtls WHERE receipt_date BETWEEN :from AND :to;
  • Identifying failed or non-successful responses by joining to processing results on the edit identifier.
  • Reporting on servicer turnaround time by comparing DOC_CREATED_DATE with RECEIPT_DATE.
  • Auditing which concurrent request loaded a given response via REQUEST_ID.

Related Objects

The documented foreign-key relationships connect this table to the following objects, which are the most significant for joining and tracing processing outcomes:

Together these objects form the persistence and processing chain for Common Record responses, enabling the Financial Aid module to consume, validate, and report on servicer communications within Oracle EBS.