Search Results igf_sl_cod_temp

Overview

The IGF.IGF_SL_COD_TEMP table is a component of the Oracle E-Business Suite IGF — Financial Aid module. As documented in the ETRM repository, it is described as a "dummy table used in the COD XML Inbound process" that stores information about response codes returned during Common Origination and Disbursement (COD) processing. In Oracle EBS 12.1.1 and 12.2.2, the object is registered in the IGF schema with a status of VALID and exposes 37 documented columns.

Its role in the COD XML Inbound workflow is to stage or hold response-code data temporarily while inbound XML payloads from the COD system are parsed and validated before the results are consumed by downstream Financial Aid processes. Because it functions as a staging or dummy construct rather than a transactional master, its lifecycle is typically tied to the inbound processing batch rather than to long-term persistence.

The heuristic Data Vault classification mined from the foreign-key structure is standalone. This suggests that, from a modelling perspective, the table is not tightly integrated into a parent-child relationship network within the vault pattern. A standalone classification implies that IGF_SL_COD_TEMP behaves as an isolated staging entity rather than as a true hub, link, or satellite within a normalized Data Vault model.

Key Information Stored

The table is anchored by the primary key constraint IGF_SL_COD_TEMP_PK, which is defined on the composite columns REC_ID and LEVEL_CODE. This composite primary key is also the sole documented unique index, making it the only business-key candidate available. In practice, REC_ID identifies an individual response record, while LEVEL_CODE distinguishes the level or granularity of the response within that record.

The most significant columns fall into several functional groupings:

• Response identification: RESP_CODE, DOC_TYPE_CODE, DOC_STATUS_CODE, and PROCESS_DATE capture the response code, document type, document status, and the date the response was processed.
• Loan and MPN attributes: ELEC_MPN_FLAG, PNOTE_MPN_ID, MPN_STATUS_CODE, MPN_LINK_FLAG, BOOK_LOAN_AMT, BOOK_LOAN_AMT_DATE, and ENDORSER_AMT track Master Promissory Note and loan booking details.
• Payment and disbursement: PYMT_SERVICER_AMT, PYMT_SERVICER_DATE, YTD_DISB_AMT, TOT_ELIG_USED, SCHD_PELL_AMT, and NEG_PEND_AMT.
• Credit decision: CRDT_DECISION_STATUS, CRDT_DECISION_DATE, and CRDT_DECISION_OVRD_CODE.
• Verification and FSA codes: CPS_VERIF_FLAG, HIGH_CPS_TRANS_NUM, and FSA_CODE_1 through FSA_CODE_3.
• Standard WHO columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, along with the concurrent program context columns PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, and REQUEST_ID.

The REQUEST_ID column is particularly useful because it links each staged row back to the concurrent request that produced it, enabling traceability of inbound COD processing runs.

Common Use Cases and Queries

Because the table is a transient staging area for COD XML Inbound processing, the primary use cases revolve around troubleshooting inbound rejections, auditing response codes, and reconciling loan or disbursement amounts as reported by COD.

A typical diagnostic query retrieves response information for a given concurrent request:

SELECT rec_id, level_code, resp_code, doc_type_code,
       doc_status_code, process_date, request_id
FROM   igf.igf_sl_cod_temp
WHERE  request_id = :request_id
ORDER BY rec_id, level_code;

Analysts auditing loan amounts can aggregate booked and disbursed figures per response code:

SELECT resp_code, SUM(book_loan_amt) booked,
       SUM(ytd_disb_amt) disbursed
FROM   igf.igf_sl_cod_temp
GROUP BY resp_code;

Because the table is populated transiently by the inbound loader, data may be purged or overwritten between runs, so queries should be scoped by REQUEST_ID or PROCESS_DATE. Reporting use cases include exception reports for failed COD responses, verification flag audits, and reconciliation of servicer amounts against the loan servicing system.

Related Objects

The heuristic vault classification is standalone, and no foreign-key relationships are documented in the ETRM metadata. Nevertheless, the following objects are functionally significant when working with IGF_SL_COD_TEMP:

• FND_CONCURRENT_REQUESTS — joined via REQUEST_ID = REQUEST_ID to trace the concurrent program that populated the rows.
• FND_CONCURRENT_PROGRAMS — joined via PROGRAM_ID and PROGRAM_APPLICATION_ID to identify the loader program.
• IGF_SL_COD_XML_IN (COD XML inbound staging) — the upstream source from which response data is derived.
• IGF_AP_FIN_AID_AWD — holds Financial Aid award records that consume COD response data.
• IGF_AP_FA_DISB — disbursement records reconciled against YTD disbursement amounts.
• IGF_SL_MPN — Master Promissory Note records linked via PNOTE_MPN_ID.
• IGF_SL_PLUS_CREDIT — credit decision records compared against CRDT_DECISION_STATUS.
• IGF_SL_PELL — Pell grant records tying into SCHD_PELL_AMT.
• FND_USER — referenced indirectly via CREATED_BY and LAST_UPDATED_BY.

Because these joins are functional rather than enforced by foreign keys, referential integrity must be validated at the application layer, and administrators should confirm column data types and naming across releases when constructing queries.