Search Results ce_forecast_headers_s

Overview

CE_FORECAST_HEADERS_PKG is the header-level maintenance package for the Oracle Cash Management forecasting subsystem. In Oracle E-Business Suite 12.1.1 and 12.2.2, Cash Management allows users to build forecasts composed of a header, rows, columns, and intersecting cells. The header record in CE_FORECAST_HEADERS defines the forecasting template context — its name, currency, calendar, and whether the source is generated from another module, manually entered, or based on a spreadsheet. This package encapsulates the DML and validation logic that keeps those header rows consistent with their dependent row, column, and cell records.

The package body is classified as OTHER in the ETRM metadata, meaning it is an internal application-level package rather than a public, published API. It is not referenced by any other database object, but it invokes a number of internal dependencies including APP_EXCEPTION, APP_EXCEPTIONS, FND_MESSAGE, and CE_FORECAST_COLUMNS_PKG, indicating that error handling follows the standard Oracle Application Object Library conventions (FND_MESSAGE for user-facing messages and APP_EXCEPTION for raising them).

Key Procedures and Functions

• SPEC_REVISION / BODY_REVISION — Version identifiers used by the standard Oracle Forms/Reports revision-check mechanism. They expose the package specification and body revision strings so callers can verify that a compiled form or report is running against the expected package revision.
• CHECK_UNIQUE — Validates that a forecast header does not violate uniqueness constraints before insert or update. This typically guards against duplicate forecast names or conflicting header attributes within a ledger or user context.
• INSERT_ROW — Inserts a new row into CE_FORECAST_HEADERS, populating the standard WHO columns and any derived attributes required for the new forecast header.
• LOCK_ROW — Acquires a row-level lock on the target header record (SELECT ... FOR UPDATE) to prevent concurrent modification while a form or process is editing the header.
• UPDATE_ROW — Applies changes to an existing header row, including the WHO update columns, after the caller has obtained a lock.
• DELETE_ROW — Removes a single header row from CE_FORECAST_HEADERS, generally after dependent rows, columns, and cells have been handled.
• DELETE_FORECASTS — A bulk delete routine used to purge one or more forecast headers, referenced in the dependency metadata alongside CE_FORECASTS, CE_FORECAST_ROWS, CE_FORECAST_COLUMNS, and CE_FORECAST_CELLS. This indicates cascading cleanup of the lower-level forecast structures.

Tables Accessed

The package reads and writes the Cash Management forecast object model. CE_FORECAST_HEADERS is the primary table maintained by INSERT_ROW, UPDATE_ROW, and DELETE_ROW. CE_FORECAST_HEADERS_S is the corresponding audit/shadow table populated by the Oracle Forms automatic history mechanism and referenced during save and delete operations. CE_FORECAST_ROWS, CE_FORECAST_COLUMNS, and CE_FORECAST_CELLS are the subordinate structures enumerated by DELETE_FORECASTS to remove the full hierarchy when a header is purged. CE_FORECASTS holds the higher-level forecast definition to which headers belong, and is also processed by DELETE_FORECASTS. CE_FORECAST_COLUMNS_PKG is called for column-level logic, and DUAL/STANDARD are used for trivial lookups and package compilation support.

Usage Notes

CE_FORECAST_HEADERS_PKG is invoked primarily from the Cash Management forecast maintenance forms, where Oracle Forms PL/SQL blocks call LOCK_ROW, INSERT_ROW, UPDATE_ROW, and DELETE_ROW in response to end-user actions. CHECK_UNIQUE is called during validation before the row is committed. DELETE_FORECASTS is used by the concurrent or form-driven cleanup path when a forecast header and its full row/column/cell grid must be removed together. Because the package is not a published API and is referenced by no other database object, customizations should call it only where the standard forms do; direct invocation from custom concurrent programs is possible but must respect the same locking and WHO-column conventions that the forms observe.