Search Results mpn_ind

Overview

The APPS.IGF_SL_DL_PNOTE_RESP view is a reporting and integration object within the Oracle E-Business Suite Financial Aid module, specifically the Student Loan (IGF) component that supports the U.S. Federal Direct Loan processing. It exposes data captured in response to promissory note (P-Note) processing activities performed by the institution and transmitted to or received from the Common Origination and Disbursement (COD) system. In Oracle EBS 12.1.1 and 12.2.2 the object is registered with FND Design Data reference IGF.IGF_SL_DL_PNOTE_RESP and carries a status of VALID.

The view is defined as a multi-org secured view. This means it automatically restricts rows returned to the current operating unit (ORG_ID) of the session under which data is queried, and silently ignores records belonging to other operating units. This behavior is critical when the view is used in concurrent programs, OBIEE extracts, or custom reports, since the ORG_ID predicate is applied transparently by the EBS multi-org security views layered on top of Oracle HRMS organizations.

Underlying Base Objects

According to the ETRM metadata, IGF_SL_DL_PNOTE_RESP is defined over a single base object: APPS.IGF_SL_DL_PNOTE_RESP_ALL. The _ALL suffix confirms that the table is partitioned logically by operating unit via ORG_ID, and that the view is the filtered "secured" projection of that table. This is the standard Oracle multi-org view pattern in EBS 12.1.1 and 12.2.2, in which the view hides the ORG_ID filtering clause inside the view definition itself.

Because the view is a simple projection with no joins, performance is generally determined by indexes on the underlying _ALL table, notably on DBTH_ID, DLPNR_ID, PNOTE_BATCH_ID, LOAN_NUMBER, and ORG_ID. The view is consumed downstream by APPS.IGF_SL_DL_PNOTE_ACK and is referenced by dependent code in APPS.IGF_SL_REJ_WF, the workflow package that manages rejection handling for promissory notes. Practitioners should therefore treat the view as a shared contract: changes to column semantics may ripple into acknowledgement processing and the rejection workflow.

Key Columns

• DLPNR_ID – Primary key of the promissory note response record.
• DBTH_ID – Foreign key to the disbursement batch header, linking the response to a specific disbursement cycle.
• PNOTE_ACK_DATE – The date on which the promissory note acknowledgement was received. This is the column most commonly searched when users query "pnote_ack_date", as it drives reconciliation of loan acknowledgement timing.
• PNOTE_BATCH_ID – External identifier of the P-Note batch submitted to or returned from COD.
• LOAN_NUMBER – The Direct Loan identifier for the borrower/loan combination.
• PNOTE_STATUS, PNOTE_REJ_CODES, STATUS – Status indicators returned from COD; PNOTE_REJ_CODES carries rejection reason codes consumed by IGF_SL_REJ_WF.
• PNOTE_ACCEPT_AMT – Accepted promissory note amount, useful for reconciliation against disbursed totals.
• MPN_IND, ELEC_MPN_IND – Flags indicating Master Promissory Note usage and electronic MPN processing.
• ORG_ID – Operating unit, populated by the multi-org view filter.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE – Standard EBS "who columns" used for audit and concurrent program traceability.

Common Use Cases and Queries

The most frequent use is to report acknowledged promissory notes within a date range for a given operating unit, often for financial aid compliance and reconciliation packages.

SELECT LOAN_NUMBER, PNOTE_ACK_DATE, PNOTE_STATUS, PNOTE_ACCEPT_AMT
FROM   APPS.IGF_SL_DL_PNOTE_RESP
WHERE  PNOTE_ACK_DATE BETWEEN :p_from AND :p_to;

A second common pattern inspects rejections, joining to the workflow to identify notes that require follow-up.

SELECT PNOTE_BATCH_ID, LOAN_NUMBER, PNOTE_REJ_CODES, STATUS
FROM   APPS.IGF_SL_DL_PNOTE_RESP
WHERE  PNOTE_STATUS = 'R';

Because the view is multi-org secured, no ORG_ID predicate is required; the current operating unit is applied automatically. Analysts integrating with OBIEE or extracts should still project ORG_ID explicitly when producing certification documents.