Results for “credit_card_code”

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

Overview

ASO_I_CREDIT_CARDS_V is a public APPS-owned database view shipped with Oracle E-Business Suite Order Capture (ASO). Its documented purpose is concise: it "gives credit card information." Operationally, the view exposes the enabled credit card types available for use on sales orders and order capture flows, rather than any customer cardholder data. It is a lookup-driven reference view, not a transactional table.

Because it is a database view rather than a PL/SQL API or a concurrent program, its principal consumers are reports, inquiry screens, custom SQL extracts, and integration layers that must validate or present the set of accepted credit card brands (for example, distinguishing card types at order entry, or populating a list of values in a custom form). In EBS 12.1.1 and 12.2.2 the object definition and ownership are unchanged; the 12.2.2 ETRM record lists APPS as owner with a single referenced base object, OE_LOOKUPS. The ASO_I_ prefix follows Oracle's convention for internal-facing interface views, and the _V suffix confirms its read-only view nature.

Underlying Base Objects

The view is defined over exactly one documented base object: OE_LOOKUPS, itself a view in the Order Management schema. OE_LOOKUPS in turn resolves to the FND_LOOKUPS / FND_LOOKUP_VALUES foundation tables that store Oracle Application Object Library lookup types and their enabled code values.

Specifically, ASO_I_CREDIT_CARDS_V filters OE_LOOKUPS on LOOKUP_TYPE = 'CREDIT_CARD' and ENABLED_FLAG = 'Y'. It defines the Oracle EBS credit card type list of values. Because the row source is a lookup view, records are configuration data, not user-entered operational data; they can be seeded by Oracle and additionally maintained by the system administrator. No user-defined columns, no descriptive flexfields, and no transaction identifiers are exposed. The only join/filter logic is the lookup type, the enabled flag, and an effective-date window applied against START_DATE_ACTIVE and END_DATE_ACTIVE.

Key Columns

• CREDIT_CARD — maps to MEANING on OE_LOOKUPS; the descriptive, user-visible name of the credit card type (for example, the display label shown in a list of values).
• CREDIT_CARD_CODE — maps to LOOKUP_CODE on OE_LOOKUPS; the short internal code used to store the credit card type on order and payment records.

The view text additionally constrains the effective date, so a card type is returned only when the system date falls within NVL(START_DATE_ACTIVE, SYSDATE) and NVL(END_DATE_ACTIVE, SYSDATE), meaning records with no start date are treated as always effective and records with no end date are treated as open-ended.

Common Use Cases and Queries

Typical usage includes report parameter lists, order-entry validations, data-conversion validation of incoming card type codes, and reconciliation extracts that verify a card code stored on an order still exists as an enabled lookup value.

Basic retrieval of all currently enabled card types:

SELECT credit_card, credit_card_code FROM apps.aso_i_credit_cards_v ORDER BY credit_card;

Validation of a specific code during conversion or interface processing:

SELECT credit_card FROM apps.aso_i_credit_cards_v WHERE credit_card_code = :p_card_code;

Cross-check against configured lookup values, including disabled or date-expired entries:

SELECT l.lookup_code, l.meaning, l.enabled_flag, l.start_date_active, l.end_date_active FROM apps.fnd_lookup_values l WHERE l.lookup_type = 'CREDIT_CARD' AND l.view_application_id = 0 ORDER BY l.lookup_code;

Because the view returns only enabled and currently effective values, it is unsuitable for historical auditing of retired card types; use FND_LOOKUP_VALUES for that requirement. Access is read-only and governed by standard APPS schema privileges.