Search Results trx_type




Overview
Explore in AI Chat

Overview

The CE.CE_FORECAST_ROWS table is a core configuration object within the Oracle Cash Management (CE) module of Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the source transaction definitions that comprise each row of a cash forecast template. Where CE_FORECAST_HEADERS defines the template itself, CE_FORECAST_ROWS defines the individual selection rules — one row per source of projected cash flow — that determine which transactions (payables, receivables, payroll, orders, budgets, and others) are pulled into the forecast. The physical structure contains 87 documented columns, reflecting the breadth of source systems that Cash Management can forecast. Because the Forecast Templates form is fully model-driven, the rows created here drive the runtime generation of forecast data stored in downstream cell tables. The metadata suggests a satellite-leaning classification under a Data Vault heuristic, meaning the table is best modeled as descriptive context attached to a parent business key (the forecast header) rather than as an independent hub or a true many-to-many link.

Key Information Stored

The surrogate primary key is FORECAST_ROW_ID (enforced by unique index CE_FORECAST_ROWS_U1 and constraint CE_FORECAST_ROWS_PK). The principal business-key candidate is the composite of FORECAST_HEADER_ID and ROW_NUMBER, enforced by unique index CE_FORECAST_ROWS_U2; this combination guarantees a stable, user-visible sequencing of template rows within a header.

  • FORECAST_HEADER_ID — foreign key to CE_FORECAST_HEADERS; the template to which the row belongs.
  • ROW_NUMBER — user-assigned sequence establishing the order of template rows.
  • TRX_TYPE — the source transaction type (for example APP, ARR, PAY, or budget-related values), validated against lookup type FORECAST_TRX_TYPE. This is the most commonly filtered column and the one most likely to appear in a user query.
  • FORECAST_METHOD — indicates whether historical (P) or current (C) transactions are selected; applicable only to APP and ARR, and fixed to P for PAY.
  • LEAD_TIME — the offset added to a transaction date to derive the projected cash date.
  • DESCRIPTION — free-text description of the template row.
  • RECEIPT_METHOD_ID — AR receipt method; relevant only when TRX_TYPE is ARR.
  • BANK_ACCOUNT_ID — bank account restricting the source data for APP, ARR, and PAY rows.
  • PAYMENT_METHOD and PAY_GROUP — AP-specific selection criteria.
  • SET_OF_BOOKS_ID, ORG_ID, and LEGAL_ENTITY_ID — multi-organization and ledger context.
  • CODE_COMBINATION_ID and CHART_OF_ACCOUNTS_ID — accounting flexfield filters used for budget and encumbrance rows.
  • CRITERIA_CATEGORY with CRITERIA1–CRITERIA15 — a flexible descriptor block for extended selection criteria.
  • Standard WHO columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical usage includes auditing template configuration, migrating forecast templates between environments, and reporting on which source transaction types feed a given forecast. Because TRX_TYPE is a lookup-backed column, a frequent query pattern joins it to FND_LOOKUPS to resolve the meaning of the code. A representative query retrieving all rows for a template might read:

SELECT r.row_number, r.trx_type, r.description, r.forecast_method, r.lead_time
FROM ce.ce_forecast_rows r, ce.ce_forecast_headers h
WHERE r.forecast_header_id = h.forecast_header_id
AND h.forecast_header_id = :header_id
ORDER BY r.row_number;

To answer the common question of which templates reference a particular transaction type, filter directly on TRX_TYPE and join to the header to obtain the template name. Configuration reconciliation reports commonly join BANK_ACCOUNT_ID to AP_BANK_ACCOUNTS_ALL and RECEIPT_METHOD_ID to AR_RECEIPT_METHODS to confirm that referenced source objects remain valid before a forecast run.

Related Objects

The table participates in a well-defined dependency web. The most significant related objects are:

Because the table is configuration rather than transactional data, it is typically populated through the Forecast Templates form or via template migration tools rather than through public APIs, and direct DML should be restricted to controlled migration or diagnostic activity.