Search Results cash_activity_date




Overview

APPS.CE_CP_XTI_V is a VALID Oracle E-Business Suite internal view owned by the APPS schema and mapped to the FND Design Data object CE.CE_CP_XTI_V. The suffix "XTI" indicates its role as a cross-tier interface that joins Oracle Cash Management (CE) bank account and cash activity data with Oracle Treasury (XTR) deal-level information. The view is classified as "Internal" and is flagged with an Oracle Internal Use Only warning: Oracle Corporation does not support access to Oracle Applications data through this object except from standard Oracle Applications programs.

For users investigating cash_activity_date, this view is directly relevant because CASH_ACTIVITY_DATE is one of the eight columns exposed. The view presents a flattened, reconciliation-oriented picture of treasury deals and their associated cash movements, allowing the cash activity date, deal type, functional-currency amount, and reconciliation state to be consumed in a single query. It is most often used behind the scenes by cash positioning, bank reconciliation, and treasury integration flows rather than by end-user reporting tools, and it is not referenced by any other database object, placing it at the leaf of the dependency tree.

Underlying Base Objects

The documented dependency list for APPS.CE_CP_XTI_V consists of three objects:

  • CE_BANK_ACCTS_GT_V (VIEW) — a Cash Management global temporary view supplying bank account context, notably the BANK_ACCOUNT_ID that ties cash activity to a specific internal bank account.
  • XTR_DEAL_DATE_AMOUNTS (SYNONYM) — a Treasury synonym providing deal-level date and amount information, including the cash activity date and the base (functional currency) amount.
  • XTR_PARTY_INFO (SYNONYM) — a Treasury synonym supplying counterparty and party-related detail associated with the deal.

Because two of the three dependencies are synonyms, the physical tables reside in the Treasury schema and are surfaced to APPS through private or public synonyms, while the bank account component is delivered as a global temporary view. The view itself defines no storage and is not referenced by any downstream database object, so it functions purely as a read-only presentation layer.

Key Columns

  • REFERENCE_ID (NUMBER) — reference identifier that uniquely labels the cash/treasury activity row.
  • BANK_ACCOUNT_ID (NUMBER, 15) — bank account identifier linking the row to a specific internal bank account.
  • CASH_ACTIVITY_DATE (DATE) — the cash activity date, the principal date used for positioning cash flows and matching treasury deals to bank statement activity.
  • DEAL_NUMBER (NUMBER) — the treasury deal number associated with the transaction.
  • BASE_AMOUNT (NUMBER) — payment amount expressed in the functional currency.
  • INDICATIVE_FLAG (VARCHAR2) — indicates whether the deal or amount is indicative rather than firm.
  • DEAL_TYPE (VARCHAR2) — classification of the treasury deal.
  • RECONCILED_REFERENCE (NUMBER) — reference used to identify the reconciled counterpart, supporting reconciliation status analysis.

Common Use Cases and Queries

Typical usage centers on retrieving treasury-related cash activity by date and bank account, verifying deal amounts in the functional currency, and auditing reconciliation status. A representative query filtering on the searched term is:

  • SELECT reference_id, bank_account_id, cash_activity_date, deal_number, base_amount, deal_type, reconciled_reference FROM apps.ce_cp_xti_v WHERE cash_activity_date BETWEEN :p_start AND :p_end;
  • SELECT bank_account_id, deal_type, SUM(base_amount) FROM apps.ce_cp_xti_v WHERE cash_activity_date = :p_date GROUP BY bank_account_id, deal_type;
  • SELECT deal_number, cash_activity_date, base_amount FROM apps.ce_cp_xti_v WHERE reconciled_reference IS NULL AND indicative_flag = 'Y';

These patterns support cash positioning by date, aggregation of deal exposure per bank account, and identification of unreconciled or indicative transactions. Because the view is designated internal and unsupported for direct customer access, any such queries should be validated against Oracle's support policy before being embedded in production customizations; supported alternatives should be pursued where Oracle supplies them.