Search Results ce_200_reconciled_v




Overview

CE_200_RECONCILED_V is a standard Oracle E-Business Suite database view owned by the APPS schema and defined within the Cash Management (CE) product. Its documented purpose is to present reconciled Oracle Payables payments for the specific business process of unreconciling. In the bank reconciliation lifecycle, once a payment has been matched to a bank statement line and subsequently reconciled, there are situations where that reconciliation must be reversed — for example, when the payment was matched to the wrong statement line, when the statement line was misidentified, or when the reconciliation was performed in error. CE_200_RECONCILED_V provides the queryable data set that the Cash Management reconciliation engine uses as the source for identifying and selecting payments eligible for unreconciliation.

The view is client-extension compatible and returns a row identifier along with a fixed discriminator value and the transaction type label "PAYMENT," which distinguishes it from the parallel receivable-side views used elsewhere in Cash Management (for example those surfacing miscellaneous receipts or AP/AR other transactions). Its columns supply the amounts, currencies, statuses, dates, and statement line context needed both by the unreconcile transaction processing and by custom reconciliation reporting.

Underlying Base Objects

The view is defined over a substantial set of synonyms, views, and packages across the Payables, Cash Management, General Ledger, and Applications Foundation layers. Documented referenced objects include:

The join chain effectively anchors each reconcilable payment to its AP check record, its bank account definition, and the statement line to which it was reconciled, while deriving currency and amount semantics from the ledger and bank account setup.

Key Columns

  • ROWID – Row identifier of the underlying AP check record, used as the selection handle during unreconciliation.
  • STATEMENT_LINE_ID – The bank statement line against which the payment was reconciled.
  • BANK_ACCOUNT_ID – The bank account associated with the payment.
  • CHECK_ID – The Payables payment (check) identifier.
  • CHECK_NUMBER – Formatted payment number presented to the user.
  • CURRENCY_CODE and transaction currency class – Derived as FUNCTIONAL, BANK, or FOREIGN using DECODE logic comparing the payment currency to the ledger (SOB) and bank account currencies.
  • AMOUNT and converted amount – The payment amount and its equivalent in functional or bank currency depending on classification.
  • Reconciled/cleared amount – Status-aware value: CLEARED_AMOUNT when reconciled, full AMOUNT for voided or stopped payments.
  • STATUS_LOOKUP_CODE – Payables payment status, with CLEARED BUT UNACCOUNTED and RECONCILED UNACCOUNTED normalized to RECONCILED.
  • ACCOUNTING_DATE, CHECK_DATE, CLEARED_DATE, FUTURE_PAY_DUE_DATE, exchange dates – Supporting dating used for reconciliation and reversal logic.

Common Use Cases and Queries

Typical usage includes custom reconciliation reports listing payments available for unreconciliation, diagnostic queries during reconciliation troubleshooting, and validation before invoking the standard Unreconcile function in the Cash Management workbench.

  • List reconciled payments eligible for reversal:
    SELECT check_number, amount, currency_code, status_lookup_code, cleared_date
    FROM ce_200_reconciled_v
    WHERE bank_account_id = :p_bank_account_id;
  • Find a specific payment's reconciliation context:
    SELECT check_id, statement_line_id, accounting_date
    FROM ce_200_reconciled_v
    WHERE check_number = :p_check_number;
  • Report cleared amounts by currency class:
    SELECT currency_code, SUM(amount) total_amt
    FROM ce_200_reconciled_v
    GROUP BY currency_code;

Security is enforced through CE_SECURITY_PROFILES_GT and FND_GLOBAL, so query results are naturally limited to the bank accounts accessible to the logged-in user. Because the view is a supported EBS database object, it can be safely referenced from custom reports, concurrent programs, and integration extracts without modifying base tables.