Search Results delete_forecast_cells

Overview

The APPS.XTR_FORECAST_PERIODS_PKG package is a table-handling API within the Oracle E-Business Suite Treasury (ETRM) module. Its stated purpose, per the package header, is to group all the procedures and functions responsible for table handling of the XTR_FORECAST_PERIODS table. This table stores the period definitions that subdivide a treasury forecast — that is, the individual time buckets (daily, weekly, monthly, and so forth) into which forecast data is organized under a given forecast header.

The package is classified as OTHER within the ETRM API taxonomy and is owned by APPS. It is a low-level, row-oriented data access layer rather than a business-process API: its procedures map closely to discrete DML operations against XTR_FORECAST_PERIODS, providing the insert, lock, update, delete, and validation primitives used by higher-level treasury forecast logic. The package declares AUTHID CURRENT_USER, so it executes with the privileges of the calling schema.

In the EBS 12.1.1 and 12.2.2 code lines, the package retains the same core structure, with the later release additionally exposing the DELETE_FORECAST_CELLS procedure that extends period maintenance to dependent forecast cells.

Key Procedures and Functions

The ETRM metadata documents six procedures for this package:

• CHECK_UNIQUE — Validates the uniqueness of a forecast period before it is inserted. It accepts a row identifier, a forecast header identifier, and a period number, and confirms that the period being added does not duplicate an existing period under the same forecast header.
• INSERT_ROW — Inserts a new row into XTR_FORECAST_PERIODS. It returns the generated forecast period identifier and row identifier, and populates the period attributes (period number, level of summary, length of period, length type) together with the standard EBS audit columns (created by, creation date, last updated by, last update date, last update login).
• LOCK_ROW — Acquires a row-level lock on an existing forecast period record. It takes the full set of period and audit columns, ensuring the record is not modified concurrently by another session.
• UPDATE_ROW — Updates an existing forecast period row, taking the same column set as the lock and insert operations.
• DELETE_ROW — Deletes a single forecast period row from XTR_FORECAST_PERIODS.
• DELETE_FORECAST_CELLS — Deletes the forecast cells associated with a forecast period. This procedure is the object targeted by the common search term delete_forecast_cells, and it supports the removal of the underlying forecast data cells so that period definitions can be maintained without orphaning cell records.

Tables Accessed

The package operates against the following tables through APPS synonyms:

• XTR_FORECAST_PERIODS — The primary table handled by the package. All row management operations (CHECK_UNIQUE, INSERT_ROW, LOCK_ROW, UPDATE_ROW, and DELETE_ROW) read from or write to this table, which holds the period-to-forecast-header relationship and period attributes.
• CE_FORECAST_COLUMNS_S — A Cash Management forecast columns table referenced by the package, providing the column definitions used to build and interpret the forecast period structure. Its involvement reflects the dependency of forecast periods on the forecast column layout established in the Cash Management forecast model.

Usage Notes

As a row-handling package, XTR_FORECAST_PERIODS_PKG is typically invoked indirectly rather than by end users. It is called by the ETRM forecast maintenance forms when a user creates, edits, or removes forecast periods, and by other Treasury packages that programmatically manage forecast definitions. The metadata indicates the package is referenced by one other package, confirming its role as a shared dependency within the ETRM forecast stack.

Custom code extending treasury forecasts should call these procedures rather than issuing direct DML against XTR_FORECAST_PERIODS, so that uniqueness validation, row locking, audit column population, and coordinated cell deletion are preserved. In particular, DELETE_FORECAST_CELLS should be executed before removing forecast periods when dependent cell data exists, to maintain referential consistency between period definitions and forecast content.