Search Results fv_refunds_voids_all




Overview
Explore in AI Chat

Overview

The AP_CHECKS_ALL table is the central repository for all supplier payment data within the Oracle E-Business Suite Payables module (AP). It stores a comprehensive record for every payment instrument issued, including physical checks, electronic funds transfers (EFT), and wire transfers. As a multi-organization table (indicated by the "_ALL" suffix), it contains payment records for all operating units, with data partitioned by the ORG_ID column. This table is fundamental to the payment lifecycle, tracking a payment from its creation in a payment batch (check run) through its printing, issuance, clearing, and potential voiding. Its integrity is enforced by multiple primary and foreign key relationships, linking it to core entities like bank accounts, vendors, invoices, and payment instructions.

Key Information Stored

The table's structure captures the full spectrum of payment attributes. The primary identifier is the system-generated CHECK_ID. Critical business columns include CHECK_NUMBER, AMOUNT, CURRENCY_CODE, and CHECK_DATE. The table records the payment's financial context through BANK_ACCOUNT_ID and CE_BANK_ACCT_USE_ID, linking to the specific bank account used. Payee details are stored in VENDOR_ID and VENDOR_SITE_ID. The payment's source and status are tracked via CHECKRUN_ID (linking to the payment batch), STATUS_LOOKUP_CODE (e.g., 'ISSUED', 'CLEARED', 'VOIDED'), and CLEARED_DATE. For foreign currency transactions, columns like EXCHANGE_RATE_TYPE and EXCHANGE_RATE are populated. The table also supports document sequencing (DOC_SEQUENCE_ID, DOC_SEQUENCE_VALUE) and integration with Oracle Payments (IBY_PAY_INSTRUCTIONS_ALL) for electronic payments.

Common Use Cases and Queries

This table is central to payment inquiry, reconciliation, and audit reporting. Common operational queries include listing all payments for a specific vendor, finding payments issued from a particular bank account within a date range, or identifying uncleared checks. A typical query for payment details joins to related vendor and bank tables:

  • SELECT ac.check_number, ac.amount, ac.check_date, pv.vendor_name, aba.bank_account_name FROM ap_checks_all ac, po_vendors pv, ap_bank_accounts_all aba WHERE ac.vendor_id = pv.vendor_id AND ac.bank_account_id = aba.bank_account_id AND ac.org_id = :p_org_id AND ac.check_date BETWEEN :p_from_date AND :p_to_date;

For reconciliation, queries often filter on STATUS_LOOKUP_CODE and CLEARED_DATE. The table is also essential for tracing payment history, as the CHECK_ID is a foreign key in the AP_INVOICE_PAYMENTS_ALL table, which links payments to the specific invoices they settle.

Related Objects

AP_CHECKS_ALL has extensive relationships within the Payables, Cash Management, and Payments architecture. Key child tables that depend on its CHECK_ID include AP_INVOICE_PAYMENTS_ALL (invoice payment applications), AP_PAYMENT_HISTORY_ALL (status change audit), and AP_SELECTED_INVOICE_CHECKS_ALL (temporary assignment in a payment batch). It references master data from PO_VENDORS, PO_VENDOR_SITES_ALL, AP_BANK_ACCOUNTS_ALL, and FND_CURRENCIES. For electronic payments, it links to IBY_PAY_INSTRUCTIONS_ALL. The CE_BANK_ACCT_USES_ALL foreign key integrates with Cash Management for bank account reconciliation. The FV_REFUNDS_VOIDS_ALL table references it for treasury-related void transactions.