Results for “aso_i_payment_types_v”

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

Overview

ASO_I_PAYMENT_TYPES_V is a public Oracle E-Business Suite view owned by the APPS schema and registered as VALID in both release 12.1.1 and 12.2.2. It belongs to the ASO – Order Capture product family, which encompasses the quoting, order capture, and order management functionality shared with Oracle Advanced Pricing and Oracle Order Management. The view provides a simple, denormalized list of the payment types that may be associated with an order, quote, or sales agreement header. It is classified as an interface-style (I) view, meaning it is intended primarily for programmatic access—reports, concurrent programs, extensions, and external integrations—rather than for direct end-user maintenance of lookup data.

Because it accepts no bind parameters and performs no joins to transactional tables, the view functions as a lightweight reference list. Consumers can retrieve the valid payment type codes and their translated meanings without needing to be aware of the underlying lookup architecture. This decoupling is deliberate: application code and interfaces can depend on a stable view name while Oracle retains the freedom to restructure the lookup storage in future releases.

Underlying Base Objects

The view is defined exclusively over ASO_LOOKUPS, which is itself a view rather than a physical table. ASO_LOOKUPS is the Order Capture lookup repository, and in a standard EBS configuration it resolves to the FND_LOOKUP_VALUES / FND_LOOKUPS structure maintained through the Application Object Library. ASO_LOOKUPS exposes lookup types, lookup codes, meanings, descriptions, enabled flags, and related attributes in the format expected by Order Capture components.

The defining query of ASO_I_PAYMENT_TYPES_V is:

• SELECT LOOKUP_CODE, MEANING FROM ASO_LOOKUPS WHERE LOOKUP_TYPE = 'ASO_PAYMENT_TYPE'

Consequently, the view is a restricted projection: it filters ASO_LOOKUPS to the single lookup type ASO_PAYMENT_TYPE and surfaces only the code and the meaning. This is the only documented base object dependency (ETRM 12.2.2), and the view contains no aggregation, no outer joins, and no security predicates beyond those inherited from the lookup layer. Any row that is disabled or end-dated at the lookup level will not appear, so the view automatically reflects the currently enabled payment types.

Key Columns

• PAYMENT_TYPE_CODE — the lookup code drawn from LOOKUP_CODE. This is the stored, language-independent value written to order, quote, and agreement records when a payment type is selected. Because it is the persisted token, integrations should always transmit and compare this column programmatically rather than the descriptive text.
• PAYMENT_TYPE — the lookup meaning drawn from MEANING. This is the user-facing, translatable description of the payment type, suitable for display in reports, LOVs, and printed documents. Its value depends on the session language, so it must never be used as a key.

No additional columns, such as enabled flags, start/end dates, or attribute fields, are exposed. Consumers requiring that metadata must query ASO_LOOKUPS or FND_LOOKUP_VALUES directly with the ASO_PAYMENT_TYPE lookup type.

Common Use Cases and Queries

Typical applications include populating payment type selection lists in custom Order Capture forms, enriching order-line extracts with the readable payment type description, validating inbound interface data, and feeding BI Publisher or Discoverer reports that summarize orders by payment method.

A basic retrieval of all available payment types:

• SELECT payment_type_code, payment_type FROM aso_i_payment_types_v ORDER BY payment_type;

Joining the view to an order header to render a readable payment type on a report:

• SELECT h.order_number, h.payment_type_code, p.payment_type
FROM oe_order_headers_all h, aso_i_payment_types_v p
WHERE h.payment_type_code = p.payment_type_code;

Validating an inbound interface value before insert:

• SELECT COUNT(*) FROM aso_i_payment_types_v
WHERE payment_type_code = :p_payment_type_code;

Because these queries are inexpensive lookups against a small reference set, the view is safe to invoke repeatedly inside PL/SQL loops, though caching the results in a PL/SQL collection or a temporary staging table is recommended for high-volume batch processes.