Search Results ar_pmts_interface_header_n1




Overview

AR.AR_PMTS_INTERFACE_HEADER_GT is a global temporary table in the Oracle Receivables (AR) schema of Oracle E-Business Suite. It functions as a session-scoped staging area for payment interface header information, most commonly populated during the Automatic Receipts and payment remittance workflow. The table is defined with a data duration of SYS$TRANSACTION, meaning that rows are visible only to the session that inserted them and are automatically purged at the conclusion of the transaction. This behavior makes the object suitable for scratchpad processing, bulk-validated staging, and intermediate result sets used by concurrent programs, rather than for persistent storage of payment interface data.

From a Data Vault modeling perspective, the metadata classifies this object as standalone, meaning it does not act as a strict hub, link, or satellite in a heuristic Data Vault decomposition. It does, however, exhibit link-like behavior because it carries foreign key references to AR_TRANSMISSIONS_ALL and AR_PAYMENTS_INTERFACE_ALL. The classification should therefore be treated as a modeling suggestion rather than a definitive design statement.

Key Information Stored

The table contains thirteen documented columns. The most operationally significant include:

No uniqueness constraint is documented; the only index, AR_PMTS_INTERFACE_HEADER_N1, is non-unique and covers TRANSMISSION_RECORD_ID and CUSTOMER_TRX_ID.

Common Use Cases and Queries

The table is typically queried during debugging of Automatic Receipts, payment application, and remittance transmission processes. A common diagnostic pattern retrieves staged rows for a specific transmission request:

  • SELECT TRANSMISSION_REQUEST_ID, TRANSMISSION_RECORD_ID, INVOICE_NUMBER, AMOUNT_APPLIED, RECORD_STATUS FROM AR.AR_PMTS_INTERFACE_HEADER_GT WHERE TRANSMISSION_REQUEST_ID = :request_id;
  • Joining to AR_PAYMENTS_INTERFACE_ALL on TRANSMISSION_RECORD_ID to reconcile staged headers with their payment interface lines.
  • Filtering by RECORD_STATUS to identify rows that failed validation or remain pending.
  • Inspecting DEFAULT_BY and PRECISION columns to confirm that amount defaults were applied consistently.

Because the table is session-scoped, queries must run within the same session that populated it; cross-session reporting returns no rows.

Related Objects

The most significant related objects are identified through documented foreign key relationships:

  • AR.AR_TRANSMISSIONS_ALL — referenced by TRANSMISSION_REQUEST_ID.
  • AR.AR_PAYMENTS_INTERFACE_ALL — referenced by TRANSMISSION_RECORD_ID.
  • AR.AR_PMTS_INTERFACE_HEADER_N1 — supporting non-unique index on TRANSMISSION_RECORD_ID and CUSTOMER_TRX_ID.
  • APPS.AR_PMTS_INTERFACE_HEADER_GT — the APPS synonym through which concurrent programs and forms access the table.

These relationships make the table a transient bridge between the payment interface and the transmission request layers during receipt processing.