Results for “payment_schedule_code”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

XTR_TERM_ACTION_REQUESTS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, belonging to the XTR (Treasury) product family. It is classified as a VIEW object type and carries a VALID status in both the 12.1.1 and 12.2.2 releases. The view exposes a consolidated list of term action requests raised against treasury deals, specifically retail term deposit actions and mass rate update actions, and is intended to support operational review of pending treasury activity rather than to act as a transactional entry point.

The defining characteristic of this view is its use of a UNION ALL to merge two logically distinct populations of the same underlying term action data. The first branch projects "RETAIL" as the CALL_FROM value, representing individual or retail-level action requests. The second branch projects "RATE" as the CALL_FROM value, representing mass interest rate updates applied across deals. Any downstream report or integration reading this view therefore receives a single, uniformly shaped result set that distinguishes the two request categories via the CALL_FROM column.

Underlying Base Objects

The view is defined over a single base object: XTR_TERM_ACTIONS, referenced in the metadata as a SYNONYM owned by APPS. All columns returned by the view are drawn from this one table; no join to XTR_DEALS or any other treasury entity is present in the documented view text.

The two UNION ALL branches apply different filters and transformations to XTR_TERM_ACTIONS. The retail branch derives its effective date using a nested NVL, preferring INCREASE_EFFECTIVE_FROM_DATE, then FROM_START_DATE, and finally EFFECTIVE_FROM_DATE, and it hard-codes a literal DEAL_NO of 0 together with zero values for PRINCIPAL_ADJUST and NEW_INTEREST_RATE. The rate branch selects DISTINCT EFFECTIVE_FROM_DATE and is restricted by NVL(MASS_RATE_UPDATE,'N') = 'Y' and NEW_INTEREST_RATE IS NOT NULL, guaranteeing that only genuine mass rate updates carrying a new rate qualify. Because both branches are filtered, the view is lighter than the base table and is not a full projection of XTR_TERM_ACTIONS.

Key Columns

• EFFECTIVE_DATE — The normalized effective date of the request. Retail rows resolve it through the INCREASE_EFFECTIVE_FROM_DATE / FROM_START_DATE / EFFECTIVE_FROM_DATE NVL chain, while rate rows use EFFECTIVE_FROM_DATE directly.
• CREATED_ON — Timestamp from the base table indicating when the term action record was created; useful for ageing and audit analysis.
• PAYMENT_SCHEDULE_CODE — Identifier of the payment schedule associated with the action, supporting grouping by schedule profile.
• DEAL_NO — Deal number for retail requests; set to a literal 0 for rate rows, since mass rate updates are not tied to a single deal in this projection.
• PRINCIPAL_ADJUST — Principal adjustment amount for retail actions; populated as 0 for rate actions.
• NEW_INTEREST_RATE — The new interest rate applied, carried on both branches; mandatory for rate rows and constant (0) on retail rows.
• CALL_FROM — Discriminator column with values 'RETAIL' or 'RATE', identifying which branch produced the row and therefore which business process owns the request.

Common Use Cases and Queries

The view is typically consumed to monitor outstanding term action requests by category and to feed interface or reconciliation processes that must treat retail actions and mass rate updates uniformly. A representative query listing all requests ordered by effective date is:

SELECT call_from, deal_no, effective_date, payment_schedule_code, principal_adjust, new_interest_rate, created_on FROM xtr_term_action_requests_v ORDER BY effective_date, call_from;

To isolate mass rate updates for review before they take effect:

SELECT deal_no, effective_date, new_interest_rate FROM xtr_term_action_requests_v WHERE call_from = 'RATE' ORDER BY effective_date;

For ageing analysis of retail requests:

SELECT deal_no, payment_schedule_code, effective_date, principal_adjust, TRUNC(SYSDATE) - TRUNC(created_on) age_days FROM xtr_term_action_requests_v WHERE call_from = 'RETAIL';

Because DEAL_NO is meaningless (0) for rate rows, report logic should always filter or branch on CALL_FROM before joining the view to deal-level tables.