Search Results payment_number

Overview

The OE_AK_HEADER_PAYMENTS_V view is a public Oracle E-Business Suite database object owned by the APPS schema and registered as a VALID view within the Order Management (ONT) product family. It is defined as a simple projection over a single base table, OE_PAYMENTS, and exposes the payment attributes associated with order headers and lines. The view takes its name from the "AK" (Oracle Application Framework / AK region) naming convention frequently used for descriptive or discoverability views consumed by Oracle Forms, OAF pages, and integration interfaces.

In Oracle EBS 12.1.1 and 12.2.2, this view serves as a read-only reporting and integration surface for payment data captured against sales orders. Rather than requiring external consumers to query OE_PAYMENTS directly, it provides a stable, named projection that downstream code, concurrent programs, and custom reports can rely on. Because it is a view rather than a table, all DML against it ultimately resolves to the underlying OE_PAYMENTS table, and no independent triggers or constraints are stored on the view itself.

Underlying Base Objects

The documented metadata identifies a single referenced base object: OE_PAYMENTS (accessed via a synonym). The view text is a straightforward SELECT of enumerated columns from that table, with several notable expressions appended to the select list:

• PAYMENT_NUMBER — surfaced directly from OE_PAYMENTS.
• LOCK_CONTROL — surfaced directly from OE_PAYMENTS.
• Three RPAD expressions producing literal placeholder strings: RPAD('X', 1, '-'), RPAD('T', 1, '-'), and RPAD('X', 30, '-'). These resolve to the constants 'X', 'T', and a 30-character string of 'X' characters padded with hyphens. Their purpose is to supply fixed values that the consuming AK/OAF layer expects for display or key handling; they carry no business meaning.

Because the view is defined over a single base table with no joins, its row cardinality and ordering mirror OE_PAYMENTS exactly. Column-level DML privileges on the APPS.OE_PAYMENTS object govern any write operations, and the view is therefore best treated as a read-only reporting artifact.

Key Columns

The view exposes a broad set of payment, credit card, and audit columns. Important ones include:

• PAYMENT_NUMBER — the primary user-facing identifier for a payment record; commonly used in searches, receipts, and reconciliation reports.
• HEADER_ID / LINE_ID — foreign keys linking the payment to the order header and, where applicable, the order line.
• PAYMENT_TYPE_CODE — classifies the payment (for example, credit card, check, or prepaid).
• PAYMENT_AMOUNT and PREPAID_AMOUNT — monetary values captured against the order.
• CHECK_NUMBER — check identifier for check-type payments.
• CREDIT_CARD_CODE, CREDIT_CARD_NUMBER, CREDIT_CARD_HOLDER_NAME, CREDIT_CARD_EXPIRATION_DATE, CREDIT_CARD_APPROVAL_CODE, CREDIT_CARD_APPROVAL_DATE — credit card authorization and holder details.
• PAYMENT_TRX_ID, RECEIPT_METHOD_ID, PAYMENT_SET_ID, PAYMENT_COLLECTION_EVENT — integration keys linking the payment to receipt and collection processing.
• COMMITMENT_APPLIED_AMOUNT and COMMITMENT_INTERFACED_AMOUNT — commitment-tracking amounts.
• Standard audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) plus REQUEST_ID and PROGRAM_* concurrency columns.
• CONTEXT and ATTRIBUTE1 through ATTRIBUTE15 — the descriptive flexfield (DFF) structure for extensible attributes.
• CONTEXT, ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield storage.

Common Use Cases and Queries

The most frequent scenario driving users to this view is a search by PAYMENT_NUMBER, typically to reconcile an order to its payment, trace a credit card authorization, or audit receipt processing. A representative query follows:

• SELECT header_id, line_id, payment_number, payment_type_code, payment_amount, check_number, credit_card_approval_code FROM oe_ak_header_payments_v WHERE payment_number = :p_payment_number;
• SELECT header_id, payment_number, payment_amount, creation_date FROM oe_ak_header_payments_v WHERE header_id = :p_header_id ORDER BY creation_date DESC;
• SELECT payment_number, credit_card_holder_name, credit_card_expiration_date, credit_card_approval_code FROM oe_ak_header_payments_v WHERE credit_card_code IS NOT NULL;
• SELECT payment_number, receipt_method_id, payment_trx_id FROM oe_ak_header_payments_v WHERE last_update_date >= :p_since;

Because the view is unfiltered over OE_PAYMENTS, queries that omit a restrictive predicate may scan a large volume of payment rows; filtering on PAYMENT_NUMBER, HEADER_ID, or an indexed date column is recommended. The fixed RPAD placeholder columns should be ignored in reporting logic, as they are presentation aids rather than data.