Search Results payment_document_name

Overview

The AP_SLA_PAYMENTS_TRANSACTION_V view, owned by the APPS schema within the Oracle Payables (AP) module, presents payment transaction information in a denormalized form suitable for Subledger Accounting (SLA) reporting and integration. It exposes one row per payment or payment-card transaction recorded in AP_CHECKS_ALL, enriched with bank, branch, account, payee, and payment document attributes drawn from Oracle Cash Management (CE) and Oracle Trading Community Architecture (HZ) reference objects. In Oracle EBS 12.1.1 and 12.2.2, the view is documented as VALID and serves primarily as a read-only reporting and data-extraction interface.

Because the view consolidates payment identifiers, monetary amounts, bank details, and the payment document name into a single relational structure, it is commonly used in custom reports, SLA reconciliation queries, and outbound data feeds that must associate a disbursement with the physical or electronic payment instrument used. The inclusion of the PAYMENT_DOCUMENT_NAME column, sourced from CE_PAYMENT_DOCUMENTS, makes this view particularly relevant when users search for "payment_document_name," as it is one of the few Payables-facing views that surfaces the human-readable document name alongside the underlying CHECK_ID.

Underlying Base Objects

The view is defined over a set of synonymous and view objects referenced through APPS. The principal driving table is AP_CHECKS_ALL (SYNONYM), aliased as AC, which supplies payment identity, amount, date, void, and method attributes. Bank account usage is retrieved from CE_BANK_ACCT_USES_ALL (SYNONYM), joined to CE_BANK_ACCOUNTS (SYNONYM) for account numbers and to CE_BANK_BRANCHES_V (VIEW) for branch names via the branch party identifier. The bank name and account number are conditionally resolved using DECODE logic: when PAYCARD_REFERENCE_ID is null, the view returns the bank name and account number from the Cash Management tables; otherwise it returns the values stored directly on the check record, supporting payment-card transactions.

The payment document name is joined from CE_PAYMENT_DOCUMENTS (SYNONYM) using AC.PAYMENT_DOCUMENT_ID with an outer join, so payments without an assigned document still return a row. Vendor identity is resolved by a scalar subquery against HZ_PARTIES (SYNONYM), returning PARTY_NAME as VENDOR_NAME. The ETRM metadata also lists CE_BANK_AND_ACCOUNT_UTIL (PACKAGE) among referenced objects; this package is associated with bank and account utility logic used in the Cash Management data model. All joins to the Cash Management tables are outer joins, ensuring the AP_CHECKS_ALL row set is preserved.

Key Columns

• CHECK_ID — Primary payment identifier from AP_CHECKS_ALL; the join key to payment distributions and accounting entries.
• BANK_NAME — Bank name resolved conditionally; for non-card payments it derives from CE_BANK_BRANCHES_V / CE_BANK_ACCOUNTS, otherwise from the check record.
• BANK_BRANCH_NAME — Branch name from CE_BANK_BRANCHES_V.
• BANK_ACCOUNT_NUM — Account number, similarly resolved via DECODE based on PAYCARD_REFERENCE_ID.
• CHECK_NUMBER — The payment document number as recorded on the check.
• AMOUNT and BASE_AMOUNT — Entered and ledger (functional) currency amounts of the payment.
• CURRENCY_CODE — Payment currency.
• CHECK_DATE and VOID_DATE — Payment date and, where applicable, the void date.
• VENDOR_NAME — Payee party name obtained through a correlated subquery on HZ_PARTIES.
• PAYMENT_DOCUMENT_NAME — Descriptive name of the payment document from CE_PAYMENT_DOCUMENTS, the column most associated with the "payment_document_name" search.
• FUTURE_PAY_DUE_DATE — Scheduled future payment due date.
• PAYMENT_METHOD_CODE — Payment method (for example, check, wire, or electronic).

Common Use Cases and Queries

Typical scenarios include reconciling payments to bank accounts, reporting disbursements by payment document, and populating downstream systems with vendor and instrument detail. A representative query retrieving payment document names for a given vendor follows:

• SELECT check_id, check_number, payment_document_name, vendor_name, amount, currency_code, check_date FROM apps.ap_sla_payments_transaction_v WHERE vendor_name = :p_vendor;
• SELECT payment_document_name, COUNT(*), SUM(amount) FROM apps.ap_sla_payments_transaction_v WHERE check_date BETWEEN :p_from AND :p_to GROUP BY payment_document_name;
• SELECT check_id, bank_name, bank_account_num, payment_method_code FROM apps.ap_sla_payments_transaction_v WHERE payment_method_code = 'WIRE';

Because the view applies outer joins to Cash Management objects, queries should account for possible null values in BANK_NAME, BANK_ACCOUNT_NUM, and PAYMENT_DOCUMENT_NAME for payments lacking associated bank or document setup. Filtering on CHECK_DATE and PAYMENT_METHOD_CODE generally provides the most efficient access paths.