Search Results ce_reconciled_transactions_v




Overview
Explore in AI Chat

Overview

CE_RECONCILED_TRANSACTIONS_V is a public Oracle E-Business Suite view owned by the APPS schema in the Cash Management (CE) module. As its name and ETRM description indicate, it presents reconciled cash transactions—bank statement lines that have been matched to their corresponding system transactions within the bank reconciliation process. The view consolidates transaction, statement line, statement header, and bank account attributes into a single denormalized result set, allowing reconciliation activity to be reported on without joining the underlying operational tables directly.

In Oracle EBS 12.1.1 and 12.2.2, this object serves as a reporting and integration layer over the treasury reconciliation engine. Because Cash Management reconciliation data spans multiple base tables and is subject to version-specific reconciliation logic (the CE_101, CE_200, CE_222, CE_260, CE_801, and CE_999 family of views), CE_RECONCILED_TRANSACTIONS_V provides a stable, published interface that abstracts those internals from custom reports, extracts, and third-party integrations. It is commonly consumed by reconciliation dashboards, bank reconciliation inquiries, and downstream data warehouse loads.

Underlying Base Objects

The ETRM 12.2.2 metadata documents the view as defined over a set of reconciliation views and packages:

The view text itself performs the selection of the columns listed below with inline comments numbering each expression, and applies DECODE logic against CE_AUTO_BANK_MATCH.GET_INVERSE_RATE to conditionally invert the exchange rate.

Key Columns

The view exposes over sixty columns. The most significant include:

Common Use Cases and Queries

Typical uses include reconciling reported statement activity to system transactions, generating reconciliation aging and exception reports, and feeding downstream treasury and general ledger extracts. Because the view is multi-org enabled, queries should constrain by ORG_ID where reporting across operating units is required.

Example — reconciled transactions for one bank account within a date range:

  • SELECT TRX_NUMBER, TRX_DATE, TYPE_MEANING, AMOUNT, AMOUNT_CLEARED, STATUS_DSP, CLEARED_DATE, BANK_ACCOUNT_NAME
  • FROM CE_RECONCILED_TRANSACTIONS_V
  • WHERE BANK_ACCOUNT_ID = :p_bank_account_id
  •   AND CLEARED_DATE BETWEEN :p_start AND :p_end
  • ORDER BY CLEARED_DATE;

Example — unreconciled or partially cleared exception report (filtering on STATUS or AMOUNT_CLEARED <> AMOUNT) supports the identification of amounts requiring manual investigation. Example — a currency analysis joining EXCHANGE_RATE and EXCHANGE_RATE_TYPE supports revaluation and audit. Because the view draws on package functions, performance in large-volume reconciliation environments benefits from indexing on BANK_ACCOUNT_ID, STATEMENT_HEADER_ID, and TRX_ID, and from restricting the result set to a single operating unit.