Results for “ra_terms_vl”

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

Overview

ASO_I_PAYMENT_TERMS_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite. It resides in the Order Capture (ASO) product family, which underpins Oracle Order Management, Oracle Quoting, and related order-capture flows. The view is documented as VALID and is classified in the ETRM as a VIEW rather than a base table, confirming that it contains no stored data of its own and derives all content from an underlying object at query time.

Its purpose is to expose payment term definitions to Order Capture code and to external consumers—interfaces, concurrent programs, and custom reports—in a simplified, stable projection. Payment terms determine due dates, discount periods, and installment behavior for order and quote pricing. Rather than querying the terms tables directly, callers use this view so that the presentation layer remains decoupled from the underlying terms schema.

The user search term "ra_terms_vl" is the direct clue to the view's lineage: ASO_I_PAYMENT_TERMS_V is documented as being based on RA_TERMS_VL, the Oracle Receivables translatable payment terms view. This establishes the view as a thin, purpose-built wrapper rather than an independent data structure.

Underlying Base Objects

The ETRM metadata documents a single referenced base object: RA_TERMS_VL, itself a VIEW. The formal view text is:

• SELECT TERM_ID, START_DATE_ACTIVE, END_DATE_ACTIVE, BASE_AMOUNT, NAME, DESCRIPTION FROM RA_TERMS_VL

This definition reveals several important characteristics. First, the projection is column-for-column and row-for-row: ASO_I_PAYMENT_TERMS_V applies no filter predicates, no joins, and no aggregation. Every active, inactive, and future-dated term present in RA_TERMS_VL is returned. Second, the only transformation is column renaming—TERM_ID in RA_TERMS_VL is presented as PAYMENT_TERM_ID in this view, aligning the column with Order Capture naming conventions.

Third, RA_TERMS_VL is the "_VL" translatable view, meaning it resolves language-specific NAME and DESCRIPTION values through the Receivables terms translation mechanism (ultimately derived from RA_TERMS and RA_TERMS_TL). Because ASO_I_PAYMENT_TERMS_V is built on the _VL layer, it automatically inherits multilingual behavior: a session running in a given language sees payment term names and descriptions in that language where a translation exists.

Key Columns

• PAYMENT_TERM_ID — The unique identifier of the payment term, mapped from TERM_ID in RA_TERMS_VL. This is the primary key for joining to order, quote, and Receivables entities.
• NAME — The language-resolved payment term name, such as "Net 30" or "Immediate." Because it comes from the _VL layer, the value reflects the session's language.
• DESCRIPTION — The translatable descriptive text associated with the term, used for display and reporting.
• START_DATE_ACTIVE — The date on which the payment term becomes available for use. Terms with a future start date are typically not selectable.
• END_DATE_ACTIVE — The date on which the payment term is retired. A null END_DATE_ACTIVE generally indicates an open-ended term still in effect.
• BASE_AMOUNT — The base amount associated with the term definition, used in installment and discount calculations.

Common Use Cases and Queries

Typical usages include populating payment term lists of values in Order Capture extensions, validating a term before assignment to an order or quote line, and reporting on term availability windows for configuration audits. Because the view is not filtered, consumers must apply their own active-date logic.

List all currently active payment terms:

• SELECT payment_term_id, name, description FROM aso_i_payment_terms_v WHERE TRUNC(SYSDATE) BETWEEN NVL(start_date_active, TRUNC(SYSDATE)) AND NVL(end_date_active, TRUNC(SYSDATE));

Resolve the term name for an existing order header:

• SELECT t.name FROM aso_i_payment_terms_v t, oe_order_headers_all h WHERE h.payment_term_id = t.payment_term_id AND h.header_id = :header_id;

Since RA_TERMS_VL is the sole underlying object, any change to Receivables payment terms is immediately visible here, and no materialized or cached copy exists. This makes the view safe for real-time lookups but unsuitable as a high-volume reporting source without indexing and filtering on PAYMENT_TERM_ID.