Search Results cn_formula_inputs_s

Overview

The APPS.CN_FORMULA_INPUTS_PKG package body is a component of the Oracle EBS Incentive Compensation (formerly Channel Revenue Management / Trade Management) product family, identified by the CN module prefix. Its principal business function is to provide a controlled, centralized Data Manipulation Layer over the CN_FORMULA_INPUTS table, which stores the individual input terms that compose a calculation formula used in incentive compensation and trade accrual processing.

Each row in CN_FORMULA_INPUTS associates a calculation formula (CALC_FORMULA_ID) with a SQL expression (CALC_SQL_EXP_ID and its foreign counterpart F_CALC_SQL_EXP_ID), a rate dimension sequence, and two behavioral control flags: CUMULATIVE_FLAG and SPLIT_FLAG. These attributes determine how a formula aggregates and splits its inputs during compensation calculation. Because this table is central to formula evaluation, direct DML is discouraged; the package encapsulates inserts, updates, deletes, and locking so that key generation, audit columns, and Multi-Org (MOAC) context are consistently applied.

The package header revision ($Header: cntfinpb.pls 120.1 2005/06/22) reflects a long-maintained code line, with R12-specific MOAC changes embedded directly in the source, evidenced by the ORG_ID parameter and accompanying marker comments.

Key Procedures and Functions

The ETRM metadata documents four procedures in this package body. Each corresponds to a standard CRUD or concurrency operation against CN_FORMULA_INPUTS.

• INSERT_ROW — Creates a new formula input record. It accepts the primary key X_FORMULA_INPUT_ID as an IN OUT NOCOPY parameter, allowing the caller to supply a value or have the package assign one (typically from a sequence), and it populates the full business and descriptive attribute set, including the MOAC ORG_ID, the fifteen ATTRIBUTE flex columns, and the standard WHO audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_BY), which default to SYSDATE and FND_GLOBAL.USER_ID.
• UPDATE_ROW — Modifies an existing formula input record, permitting changes to the business attributes and descriptive flexfield values while stamping the last-update audit columns.
• DELETE_ROW — Removes a formula input record identified by its primary key.
• LOCK_ROW — Acquires a row-level lock for the specified formula input, providing the pessimistic concurrency control that the calling forms require before updating or deleting a record.

Tables Accessed

The package operates against three documented objects, all referenced through APPS synonyms:

• CN_FORMULA_INPUTS — The base transactional table and the primary target of all INSERT, UPDATE, DELETE, and SELECT ... FOR UPDATE activity performed by this package.
• CN_FORMULA_INPUTS_S — The corresponding sequence object, used to generate unique FORMULA_INPUT_ID primary key values for new rows.
• DUAL — Used for lightweight single-row evaluations, typically to invoke SYSDATE or FND_GLOBAL calls within the package's defaulting logic.

Usage Notes

This package is an internal EBS API, classified by ETRM as OTHER rather than as a public, supported interface. It is referenced by one other package within the application, indicating that it sits beneath a higher-level business logic layer that governs formula definition and calculation setup. It is typically invoked from Oracle Forms-based setup screens for Incentive Compensation calculation formulas, where the user maintains input terms, and indirectly from concurrent programs or engine code that read formula definitions during compensation processing.

Customizations that need to insert or maintain formula inputs should call the package procedures rather than issuing direct DML against CN_FORMULA_INPUTS, so that MOAC ORG_ID population, sequence-based key assignment, and WHO audit column maintenance are preserved. Callers must initialize the FND environment and set an appropriate organization context before invocation, because the R12 MOAC changes require a valid ORG_ID. Because the procedures are not documented as a formally supported public API, customers should validate their use against the specific patch level of their 12.1.1 or 12.2.2 instance.