Search Results igf_db_dl_disb_resp

Overview

IGF_DB_DL_DISB_RESP is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the IGF (Financial Aid) product family. It exposes discharge and disbursement response data associated with the Direct Loan processing functionality used by educational institutions. The object is registered as VALID in both the 12.1.1 and 12.2.2 environments, and its structure is consistent across those releases.

The view presents a single logical row per disbursement response record, combining identifiers, monetary amounts, status tracking flags, and standard Oracle EBS audit and multi-tenant columns. Because it applies a row-level security predicate on ORG_ID, the view functions as an operational reporting layer that restricts visible records to the operating unit implied by the session's client information, rather than as a general-purpose data extraction source. This makes it suitable for concurrent programs, OAF pages, and integration components that must present only organization-appropriate disbursement response data to the end user.

Underlying Base Objects

The view is defined exclusively over the base table IGF_DB_DL_DISB_RESP_ALL. No other documented base objects participate in its definition. The "_ALL" suffix indicates that the table stores records for multiple operating units, with the ORG_ID column serving as the organization discriminator. The view is therefore a filtered projection of that table, not a join or aggregation.

The filtering logic extracts the operating unit from the USERENV('CLIENT_INFO') value. The first character of CLIENT_INFO is examined; if it is a space, a NULL is returned, otherwise the first ten characters are converted to a number. This derived value is compared against the ORG_ID on each row using NVL, with -99 substituted when no client information is available. The practical effect is that sessions without a properly initialized CLIENT_INFO context see only records with an ORG_ID corresponding to the fallback value, while normal EBS sessions see their own organization's rows. When CLIENT_INFO is not set, no rows are typically returned unless ORG_ID itself is NULL.

Key Columns

The view exposes a broad set of columns that describe the disbursement response lifecycle:

• ROW_ID — The Oracle ROWID of the underlying base table row, retained for direct row addressing.
• DDRP_ID, DBTH_ID, DISB_BATCH_ID — Internal identifiers linking the response to its parent disbursement request, batch header, and disbursement batch.
• LOAN_NUMBER, DISB_NUM, DISB_ACTIVITY, DISB_SEQ_NUM — Business keys identifying the loan and the specific disbursement activity and sequence.
• TRANSACTION_DATE, ACK_DATE — The transaction date and the date the response was acknowledged.
• DISB_GROSS_AMT, FEE_1, DISB_NET_AMT, INT_REBATE_AMT, SERVICER_REFUND_AMT — Monetary components of the disbursement, including gross, fee, net, interest rebate, and servicer refund amounts.
• LOC_DISB_GROSS_AMT, LOC_FEE_1, LOC_DISB_NET_AMT, LOC_INT_REBATE_AMT, LOC_NET_BOOKED_LOAN — Local (institution-side) counterparts to the servicer-reported amounts, allowing reconciliation between reported and booked values.
• SCH_CODE_STATUS, LOAN_NUM_STATUS, DISB_NUM_STATUS, DISB_ACTIVITY_STATUS, TRANS_DATE_STATUS, DISB_SEQ_NUM_STATUS — Field-level validation status indicators for the corresponding data elements.
• AFFIRM_FLAG, STATUS, SCHOOL_ID, USER_IDENT — Confirmation indicator, overall record status, school identifier, and the user identifier associated with the response.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard EBS audit columns.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Concurrent program context identifying the process that created or last updated the row.
• ORG_ID — The operating unit identifier used by the view's security predicate.

Common Use Cases and Queries

Typical usage centers on reviewing disbursement responses for the current operating unit, reconciling local booked amounts against servicer-reported amounts, and extracting audit or integration data for downstream processing. Because ORG_ID filtering is enforced by the view definition, queries do not normally need an explicit organization predicate when executed within a properly initialized EBS session.

Listing recent responses for the current organization:

SELECT loan_number, disb_num, disb_activity,
       transaction_date, disb_net_amt, status
FROM   apps.igf_db_dl_disb_resp
WHERE  transaction_date >= SYSDATE - 30
ORDER  BY transaction_date DESC;

Identifying records where the local booked amount differs from the reported net amount:

SELECT loan_number, disb_num, disb_seq_num,
       disb_net_amt, loc_disb_net_amt,
       (loc_disb_net_amt - disb_net_amt) variance
FROM   apps.igf_db_dl_disb_resp
WHERE  NVL(loc_disb_net_amt, 0) <> NVL(disb_net_amt, 0);

Retrieving responses that remain unacknowledged or unaffirmed for follow-up:

SELECT loan_number, disb_num, disb_batch_id,
       ack_date, affirm_flag, status
FROM   apps.igf_db_dl_disb_resp
WHERE  ack_date IS NULL
OR     NVL(affirm_flag, 'N') = 'N';

Integrations and concurrent programs should respect the CLIENT_INFO initialization requirement, as queries submitted without the correct session context will not return the expected organization's data. Where cross-organization reporting is required, the base table IGF_DB_DL_DISB_RESP_ALL should be queried directly with an explicit ORG_ID predicate rather than relying on this view.