Search Results credit_card_code




Overview
Explore in AI Chat

Overview

The SO_CREDIT_CARDS_V view is a lightweight lookup view owned by the APPS schema in Oracle E-Business Suite. It resides within the Order Entry (OE) product family and exposes the set of credit card type values that Oracle Order Management recognizes during order capture and processing. Despite the name containing the word "cards," the view does not store or expose any actual customer credit card data, numbers, or tokens. Instead it presents a simple enumeration of credit card types — such as Visa, Mastercard, and American Express — drawn from the SO_LOOKUPS lookup table. This design allows forms, concurrent programs, and integrations to resolve a stored credit card code into its user-facing description without duplicating the lookup list in application code.

The view is a standard, VALID database object in both 12.1.1 and 12.2.2, and its metadata is consistent across those releases, meaning no column or definition changes affect upgrades between them. Because it is a view rather than a table, it carries no storage of its own and inherits the security and read consistency characteristics of its underlying objects.

Underlying Base Objects

According to documented ETRM metadata for 12.2.2, SO_CREDIT_CARDS_V references two objects: the synonym SO_LOOKUPS and the package FND_GLOBAL. The view text is a straightforward projection from the lookup table:

  • SO_LOOKUPS — the base synonym resolving to the OE lookup table that stores configurable lookup types and codes. The view filters this table on LOOKUP_TYPE = 'CREDIT_CARD', restricting output to the credit card lookup set. No join to a second table is required; the view is a single-table projection with a WHERE clause.
  • FND_GLOBAL — referenced for the standard EBS session context (user, responsibility, application). Although the documented view text is a simple lookup select, FND_GLOBAL appears in the reference list as part of the standard session environment applied to lookup access, ensuring that only rows enabled for the current application context are visible.

Because the view depends on SO_LOOKUPS, any addition, deactivation, or end-dating of a credit card lookup code is reflected immediately in query results. Administrators manage the underlying values through the Application Developer responsibility's Lookups form, not by altering the view.

Key Columns

The view exposes exactly two columns, both VARCHAR2:

  • CREDIT_CARD_CODE — maps to LOOKUP_CODE in SO_LOOKUPS. This is the internal, machine-facing identifier stored on order and payment records. It matches the user search term "credit_card_code" and is the value persisted against credit card transactions.
  • CREDIT_CARD — maps to MEANING in SO_LOOKUPS. This is the display description shown to users in LOVs and reports, typically rendered with proper capitalization such as "Visa" rather than the stored code.

There is no primary key or unique index on the view itself; uniqueness of CREDIT_CARD_CODE is enforced at the SO_LOOKUPS level by lookup type and code.

Common Use Cases and Queries

The primary scenario is populating a list of values or translating a stored code into a readable label during order reporting. A typical query retrieving all active credit card types is:

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

To resolve a single code captured on an order, a developer might write:

SELECT credit_card FROM apps.so_credit_cards_v WHERE credit_card_code = :p_code;

Because the view derives from SO_LOOKUPS, only codes that exist and are enabled for the CREDIT_CARD lookup type are returned. Reports joining payment or order lines to this view should use an outer join to avoid dropping rows whose code has since been end-dated. The view is read-only and should be treated purely as a lookup interface, never as a data maintenance surface.