Search Results credit_enabled

Overview

LNS_AM_SCHEDS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It belongs to the LNS (Loans) product family and is documented in ETRM as the "Amortization Schedules View." Its purpose is to expose the amortization schedule of a loan — the sequence of periodic payment rows that decompose each installment into principal, interest, and fee components — together with the derived balances, applied amounts, transaction identifiers, and status codes required by loan servicing screens, reports, and downstream integrations.

The view joins loan header data to the underlying amortization schedule table and enriches each scheduled payment with receivables-level detail (amounts applied, amounts due original and remaining) pulled from Oracle Receivables payment schedules and receivable applications. It also resolves lookup codes into user-facing meanings and computes control flags such as reversal status, schedule origin, and credit enablement. Because it consolidates transactional detail with derived state, it is the appropriate source for any inquiry into a loan's payment stream, outstanding balances, and reversal behavior.

Underlying Base Objects

The view is defined over the following documented base objects, accessed through APPS synonyms:

• LNS_AMORTIZATION_SCHEDS — the core amortization schedule table supplying payment number, due date, principal, interest, fee, phase, balance, transaction IDs, reversal flag, and parent amortization ID.
• LNS_LOAN_HEADERS_ALL — the loan master row supplying LOAN_ID, ORG_ID, and FUNDED_AMOUNT, used as the fallback principal balance.
• LNS_DISB_HEADERS and LNS_DISB_LINES — disbursement header and line data referenced by the loan and schedule logic.
• LNS_LOAN_LINES and LNS_LOAN_AMOUNT_ADJS — loan components and amount adjustments that influence the schedule.
• AR_PAYMENT_SCHEDULES_ALL — receivables payment schedule rows supplying AMOUNT_APPLIED, AMOUNT_DUE_ORIGINAL, and AMOUNT_DUE_REMAINING by transaction component (principal, interest, fee).
• AR_RECEIVABLE_APPLICATIONS_ALL and AR_ADJUSTMENTS_ALL — cash application and adjustment activity used to derive the latest apply date and related amounts.
• FND_LOOKUPS and LNS_LOOKUPS — lookup sources that resolve codes into descriptive meanings for the view's MEANING columns.
• FND_GLOBAL — the standard context package supplying runtime session values.

The principal join path links each amortization schedule row to its parent loan via LOAN_ID, then optionally to AR payment schedules through the principal, interest, and fee transaction IDs. When a transaction ID is null, the corresponding applied amount is forced to zero by DECODE, ensuring that unscheduled or future rows do not distort totals.

Key Columns

• LOAN_ID, AMORTIZATION_SCHEDULE_ID, PAYMENT_NUMBER, DUE_DATE — loan and installment identification, plus the scheduled payment sequence and due date.
• PRINCIPAL_AMOUNT, INTEREST_AMOUNT, FEE_AMOUNT — the scheduled components of each payment.
• Principal, interest, and fee applied amounts — derived from AR_PAYMENT_SCHEDULES_ALL, zeroed when the corresponding transaction ID is null.
• Running principal balance — computed as the starting balance (stored PRINCIPAL_BALANCE, or FUNDED_AMOUNT when null) less the cumulative applied principal across the schedule, ordered by phase and payment number.
• PRINCIPAL_BALANCE and a total scheduled amount column summing principal, interest, and fee.
• Original, remaining, and (by derivation) applied amounts for each component, aggregated across the three receivables schedules.
• Latest cash apply date — a scalar subquery returning MAX(APPLY_DATE) for cash applications against the principal, interest, or fee transaction, scoped by ORG_ID.
• REVERSED_FLAG — normalized to 'N' when null, otherwise the stored value; drives reversal reporting.
• Schedule origin indicator — 'SCHEDULED' when PARENT_AMORTIZATION_ID is null, otherwise 'MANUAL'.
• MEANING columns resolved from FND_LOOKUPS / LNS_LOOKUPS for status and type codes.
• Credit status code — 'CREDIT_DISABLED' when the row is reversed; for manual schedules, 'CREDIT_ENABLED' when the applied amount equals zero, otherwise 'CREDIT_DISABLED'.
• CREATION_DATE and PARENT_AMORTIZATION_ID — audit and lineage columns.

Common Use Cases and Queries

Typical uses include loan amortization inquiries, delinquency and aging analysis, reconciliation of scheduled versus applied amounts, and integration feeds that require a flattened, fully derived schedule. A basic query returning the schedule for a loan is:

SELECT payment_number, due_date, principal_amount, interest_amount, fee_amount, principal_balance, reversed_flag
FROM   apps.lns_am_scheds_v
WHERE  loan_id = :p_loan_id
ORDER BY payment_number;

To isolate unreversed, manually created schedules that are still creditable:

SELECT loan_id, payment_number, due_date, principal_amount
FROM   apps.lns_am_scheds_v
WHERE  reversed_flag = 'N'
AND    parent_amortization_id IS NOT NULL;

To compare scheduled against applied amounts by component, summing the applied columns over the schedule identifies underpayment or overpayment at the loan level. Of particular relevance to searches for "rebill_enabled_code," the credit status logic embedded in the view — including the CREDIT_ENABLED / CREDIT_DISABLED derivation and the reversal condition — is the closest documented construct tied to credit and rebill-style behavior. Because the view's DATE_TRACK and credit columns depend on the ORG_ID and transaction links, queries should always be filtered by ORG_ID in multi-organization deployments to preserve correct results.