Results for “ce_cp_app_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CE_CP_APP_V is a Cash Management (CE) view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to serve as a Cash Positioning source for Discoverer – AP Payments. In other words, it is a reporting and integration layer that exposes Oracle Payables payment (check) activity in the normalized shape required by the Cash Positioning business flow and its associated Oracle Discoverer worksheets.

Cash Positioning in Oracle Cash Management reconciles expected and actual bank account activity against source transactions. Payments issued through Payables are one such source. CE_CP_APP_V presents those payments with a common column signature (reference identifier, bank account, cash activity date, document number, base amount, status, and payment method) so they can be unioned or aggregated alongside other cash positioning sources (receivables, manual bank transactions, and so on) without requiring the consumer to understand the internal structure of the Payables tables.

The view carries a VALID status in the ETRM repository and is therefore treated as a supported, queryable interface rather than an ad hoc object.

Underlying Base Objects

The documented referenced base object is AP_CHECKS_ALL, accessed through its APPS synonym. The view text selects exclusively from AP_CHECKS_ALL (aliased AC), so AP_CHECKS_ALL is the single underlying payment table.

The view is a UNION ALL of two branches drawn from the same base table, distinguished by the lifecycle state of the payment:

• Branch 1 — returns payments whose STATUS_LOOKUP_CODE is one of NEGOTIABLE, CLEARED, CLEARED BUT UNACCOUNTED, RECONCILED, or RECONCILED UNACCOUNTED. These represent payments already released to the bank and progressing through clearing and reconciliation.
• Branch 2 — returns payments whose STATUS_LOOKUP_CODE is ISSUED and where FUTURE_PAY_DUE_DATE IS NOT NULL. These represent future-dated payments that have been issued but are not yet due, allowing Cash Positioning to reflect expected outflows.

Both branches apply the filter VENDOR_SITE_ID IS NOT NULL, restricting the result set to supplier payments and excluding payments without a vendor site (for example, certain internal or employee-related transactions). Because the view is defined over AP_CHECKS_ALL only, no joins to suppliers, banks, or accounting distributions are performed inside the view; consumers join externally when additional attributes are required.

Key Columns

The view projects seven columns. Their relationship to the underlying AP_CHECKS_ALL columns is as follows:

• REFERENCE_ID — sourced from AP_CHECKS_ALL.CHECK_ID; the unique payment identifier used to trace back to the payment record.
• BANK_ACCOUNT_ID — sourced directly from AP_CHECKS_ALL; identifies the disbursement bank account affected by the payment and is the key used to group cash positioning activity by account.
• CASH_ACTIVITY_DATE — derived using NVL(ACTUAL_VALUE_DATE, NVL(ANTICIPATED_VALUE_DATE, NVL(FUTURE_PAY_DUE_DATE, CHECK_DATE))). This coalesce sequence selects the most economically meaningful date available: the actual value date once known, otherwise the anticipated value date, otherwise the future pay due date, otherwise the check date.
• CHECK_NUMBER — the payment document number as printed or transmitted.
• BASE_AMOUNT — the payment amount, expressed as -NVL(NVL(CLEARED_BASE_AMOUNT, CLEARED_AMOUNT), NVL(BASE_AMOUNT, AMOUNT)). Cleared amounts take precedence over original amounts, and the base (ledger) currency is preferred over the entered currency. The negated sign reflects that payments are cash outflows.
• STATUS — the payment status (STATUS_LOOKUP_CODE), indicating where the payment sits in the issue-clear-reconcile lifecycle.
• PAYMENT_METHOD — the payment method (PAYMENT_METHOD_LOOKUP_CODE), such as check, wire, or electronic funds transfer.

Common Use Cases and Queries

The view is most frequently used to populate cash positioning and bank reconciliation reports, and to reconcile payment activity against bank statements. Typical queries include retrieving all outstanding payment activity for a bank account over a date range, and summarizing exposure by payment method.

Example — detail activity for a given bank account and period:

• SELECT reference_id, check_number, cash_activity_date, base_amount, status, payment_method FROM ce_cp_app_v WHERE bank_account_id = :p_bank_account_id AND cash_activity_date BETWEEN :p_start_date AND :p_end_date ORDER BY cash_activity_date, check_number;

Example — net cash movement by payment method:

• SELECT payment_method, SUM(base_amount) cash_movement FROM ce_cp_app_v WHERE bank_account_id = :p_bank_account_id AND cash_activity_date <= :p_as_of_date GROUP BY payment_method;

Because BASE_AMOUNT is already signed as a negative outflow, summing it yields a net cash impact directly. Reports should also account for the fact that the same CHECK_ID can appear once per branch; the status-specific filters generally prevent overlap, but reconciliation logic should still be validated against the source table. When supplier, bank, or accounting detail is needed, join REFERENCE_ID back to AP_CHECKS_ALL or the related distribution tables.