Search Results commitment_applied_amount

Overview

The OE_AK_LINE_PAYMENTS_V view is a public API-support object within the Oracle Order Management (ONT) product family, defined in the APPS schema. It exposes order-line-level payment information in a flattened, denormalized form intended for consumption by Oracle Application Framework (OAF) pages, the Order Management HTML user interface, and external integration layers that reference order payments programmatically. The "AK" prefix associates the view with the Oracle Application Toolkit (AK) region model, indicating its primary role as a data source for self-service and administrative UI regions rather than as a transactional object.

A search for credit_card_code against this object resolves to the CREDIT_CARD_CODE column, which surfaces the payment card type identifier associated with a given order line payment. This column is one of several credit-card-related attributes exposed alongside approval data, masked card numbers, and expiration dates.

Underlying Base Objects

The view is defined as a single-table selection over OE_PAYMENTS, referenced through an APPS synonym. No joins, unions, or aggregations are present in the documented view text; every column is a direct projection of a column in the base table, with the sole exception of three literal expressions appended at the end of the SELECT list: RPAD('X',1,'-') as RETURN_STATUS, RPAD('T',1,'-') as DB_FLAG, and RPAD('X',30,'-') as OPERATION. These constants are OAF framework conventions that mark the entity as non-updatable through the view layer, ensuring that payment records are modified only through supported Order Management APIs such as OE_PAYMENT_PUB or the underlying order entry forms.

Key Columns

• HEADER_ID / LINE_ID — Foreign keys linking the payment record to its parent order header and order line respectively. These drive most join paths in reporting queries.
• PAYMENT_TYPE_CODE, CREDIT_CARD_CODE, CREDIT_CARD_NUMBER, CREDIT_CARD_HOLDER_NAME, CREDIT_CARD_EXPIRATION_DATE — The instrument-level attributes describing the payment method and card details.
• CREDIT_CARD_APPROVAL_CODE, CREDIT_CARD_APPROVAL_DATE — Authorization returned by the payment processor.
• PAYMENT_AMOUNT, PREPAID_AMOUNT, COMMITMENT_APPLIED_AMOUNT, COMMITMENT_INTERFACED_AMOUNT — Monetary values representing the applied payment and any amounts committed against the order.
• PAYMENT_SET_ID, PAYMENT_NUMBER — Identify the payment set and sequencing within the order.
• PAYMENT_COLLECTION_EVENT, RECEIPT_METHOD_ID, PAYMENT_TRX_ID — Integration points to Receivables collection events and receipt methods.
• CHECK_NUMBER, PAYMENT_LEVEL_CODE, LOCK_CONTROL — Supporting attributes for non-card payment methods and concurrency handling.
• Standard WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, and so forth) and fifteen ATTRIBUTE descriptive flexfield columns are exposed for audit and extensibility.

Common Use Cases and Queries

Typical uses include order inquiry screens, credit card reconciliation reports, and integration extracts feeding payment gateways or data warehouses. Because the view is a straight projection of OE_PAYMENTS, it is preferable to the base table in read-only contexts where the additional OAF literal columns are harmless.

SELECT p.header_id,
       p.line_id,
       p.credit_card_code,
       p.credit_card_approval_code,
       p.credit_card_approval_date,
       p.payment_amount
FROM   oe_ak_line_payments_v p
WHERE  p.header_id = :header_id
AND    p.credit_card_code IS NOT NULL;

For reconciliation against Receivables, join on PAYMENT_TRX_ID to AR_CASH_RECEIPTS or AR_CASH_RECEIPT_HISTORY. For reporting on payment mix, aggregate by PAYMENT_TYPE_CODE and RECEIPT_METHOD_ID. Requesters should note that the view carries no partitioning or filter predicates, so queries should always constrain on HEADER_ID, LINE_ID, or date ranges to avoid full scans of OE_PAYMENTS.