Search Results oe_payments_iface_all




Overview
Explore in AI Chat

Overview

OE_PAYMENTS_IFACE_ALL is an Order Management (ONT) interface table in Oracle E-Business Suite 12.1.1 and 12.2.2 that serves as the staging area for payment information destined for the OE_PAYMENTS table. The table stores payment records—covering credit card, check, commitment, and receipt-method-based payments—that are processed by the Order Import Program. During an order import cycle, the import concurrent program reads rows from this interface table, validates and defaults the payment data, and writes the resulting records into OE_PAYMENTS, where they become part of the permanent order structure.

The table is owned by the ONT schema and contains 63 documented columns. It has no foreign keys that depend on it, but it does reference external objects: RECEIPT_METHOD_ID points to AR_RECEIPT_METHODS, and TRXN_EXTENSION_ID points to IBY_FNDCPT_TX_EXTENSIONS. Based on the heuristic Data Vault classification derived from its foreign key structure, this object is modeled as a standalone table—it neither functions as a hub, link, nor satellite, but rather as a staging or interface construct. This classification is a modeling suggestion only; the table's operational role is transactional staging rather than master or reference data.

Key Information Stored

Because the table is an interface, most columns mirror the structure of OE_PAYMENTS while adding import-control columns. The most significant columns include:

The metadata does not document an explicit surrogate primary key or unique index for this table. Surrogate and business-key candidates such as PAYMENT_TRX_ID, PAYMENT_SET_ID, and ORIG_SYS_PAYMENT_REF appear in the column list but should be confirmed against the database constraints. Standard WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and the 15 ATTRIBUTE columns provide auditing and extensibility.

Common Use Cases and Queries

The principal use case is diagnosing Order Import failures. Support and technical teams query rows where ERROR_FLAG or INTERFACE_STATUS indicates failure, then inspect the corresponding message in the import error tables. A typical pattern is:

  • Failed payment interface rows: SELECT * FROM oe_payments_iface_all WHERE error_flag = 'Y';
  • Rows by request: SELECT * FROM oe_payments_iface_all WHERE request_id = :request_id;
  • Join to source order context: SELECT p.*, h.order_number FROM oe_payments_iface_all p, oe_order_headers_all h WHERE p.header_id = h.header_id;
  • Credit card payment subset: SELECT orig_sys_payment_ref, payment_amount, credit_card_approval_code FROM oe_payments_iface_all WHERE payment_type_code = 'CREDIT_CARD';

Reporting use cases include auditing imported prepayments, validating that PAYMENT_AMOUNT totals reconcile to order totals, and confirming that receipt methods applied match the expected configuration. Data is typically purged after successful import to keep the interface lean.

Related Objects

The following objects are most significant to OE_PAYMENTS_IFACE_ALL:

  • OE_PAYMENTS — the destination table to which validated rows are imported.
  • AR_RECEIPT_METHODS — joined on RECEIPT_METHOD_ID to resolve receipt method definitions.
  • IBY_FNDCPT_TX_EXTENSIONS — joined on TRXN_EXTENSION_ID for payment transaction extension data.
  • OE_ORDER_HEADERS_ALL / OE_ORDER_LINES_ALL — joined on HEADER_ID and LINE_ID to associate payments with orders.
  • OE_ORDER_SOURCES — referenced through ORDER_SOURCE_ID for import defaults.
  • Order Import concurrent programs — the processing engine that consumes this table.