Search Results duns_rcpt_id

Overview

IGF_SL_CL_RECIPIENT_V is a PL/SQL view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the IGF (Financial Aid) product family. It exposes a denormalized, reporting-friendly representation of the "recipient" master data used within Student Loan servicing and Common Line (CL) processing. In EBS 12.1.1 and 12.2.2 the object retains the same definition and valid status; no material structural difference is documented between the two releases.

The view consolidates identifying attributes for the three principal parties in a student loan relationship — the lender, the guarantor, and the recipient — together with the associated branch (BRC) descriptors. It also surfaces descriptive text fields that would otherwise require multiple lookups. Because the underlying records are frequently keyed by surrogate identifiers, most external references and integration interfaces resolve a recipient through the RCPT_ID column, which is why searches for "rcpt_id" routinely surface this view.

Underlying Base Objects

The view is defined over five sources. Four are base tables in the IGF schema, and one is itself a view:

• IGF_SL_CL_RECIPIENT (alias RCPT) — the driving table, holding the recipient/lender/guarantor relationship record.
• IGF_SL_LENDER (alias LND) — joined on LENDER_ID to provide the lender description.
• IGF_SL_LENDER_BRC (alias LNDB) — outer-joined to supply the non-ED branch description.
• IGF_SL_GUARANTOR (alias GUARN) — joined on GUARANTOR_ID for the guarantor description.
• IGF_SL_RECIPIENT_ALL_V (alias RCPV) — the recipient detail view, joined on RECIPIENT_ID, RECIPIENT_TYPE, and the non-ED branch identifier.

Joins to the branch tables use the NVL(..., '*') idiom on LEND_NON_ED_BRC_ID and RECIP_NON_ED_BRC_ID, ensuring that records without a branch value still match the wildcard row. The lender branch join is additionally outer-joined ((+)), so a recipient record survives even when no matching branch exists. The view propagates the standard EBS audit columns from the base recipient table.

Key Columns

• ROW_ID — the ROWID of the underlying IGF_SL_CL_RECIPIENT row; useful for direct DML targeting.
• RCPT_ID — primary surrogate identifier for the recipient record; the most commonly referenced key.
• LENDER_ID / LEND_DESCRIPTION — lender identifier and its descriptive name.
• LEND_NON_ED_BRC_ID / LEND_BRC_DESCRIPTION — non-ED lender branch and its description.
• GUARANTOR_ID / GUARN_DESCRIPTION — guarantor identifier and description.
• RECIPIENT_ID / RECIP_DESCRIPTION / RECIPIENT_TYPE — recipient identity, description, and classification.
• RECIP_NON_ED_BRC_ID / RECIP_BRC_DESCRIPTION — recipient non-ED branch and description.
• ENABLED — active/inactive flag for the recipient record.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns.
• RELATIONSHIP_CD, RELATIONSHIP_CD_DESC, PREFERRED_FLAG — relationship classification and preferred-status indicator.
• DUNS_LENDER_ID, DUNS_GUARNT_ID, DUNS_RCPT_ID — placeholder columns returned as NULL in the delivered definition, reserved for DUNS integration.

Common Use Cases and Queries

The view is typically used to resolve a recipient's descriptive context during loan processing, reconciliation, and reporting. Typical scenarios include listing all enabled recipients for a lender, retrieving the guarantor and branch description for a given RCPT_ID, and joining the view to disbursement or Common Line tables.

• Lookup by identifier: SELECT rcpt_id, recipient_id, recip_description FROM igf_sl_cl_recipient_v WHERE rcpt_id = :p_rcpt_id;
• Recipients for a lender: SELECT rcpt_id, recipient_id, guarantor_id, preferred_flag FROM igf_sl_cl_recipient_v WHERE lender_id = :p_lender_id AND enabled = 'Y';
• Branch/guarantor detail: SELECT rcpt_id, lend_brc_description, guarn_description FROM igf_sl_cl_recipient_v WHERE recipient_type = :p_type;

Because the view is a simple, non-aggregated projection, it supports direct filtering and joining without significant performance penalty, provided appropriate indexes exist on the base recipient table keys.