Search Results cn_revenue_classes_s

Overview

CN_REVENUE_CLASS_PKG is a table handler package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM taxonomy as "OTHER" (a multi-purpose utility/transactional package rather than a pure validation or query API). Its stated purpose, per the package header comment, is to serve as the Table Handler for CN_REVENUE_CLASS — the revenue class entity used within the Contracts (CN) module. A revenue class groups revenue recognition attributes such as the liability account and expense account associated with a contract line, allowing the application to determine how revenue is deferred, recognized, and posted to the general ledger. The package body encapsulates the mechanical data-manipulation logic (ID generation, insert, update, delete) required to maintain rows in the underlying CN_REVENUE_CLASSES table and its supporting sequence, shielding Forms and other callers from direct DML against the base table.

Key Procedures and Functions

The documented procedures exposed by the package are:

• GET_UID — although listed in the package header excerpt rather than the ETRM procedure list, this private helper obtains the next sequence number needed to create a new revenue class. It selects CN_REVENUE_CLASSES_S.NEXTVAL from DUAL and returns the value through its IN OUT NOCOPY parameter, ensuring each new revenue class receives a unique primary key before the insert is attempted.
• INSERT_ROW — the main insert procedure. It accepts the revenue class identifier along with its descriptive and accounting attributes (name, description, liability account, expense account, and the standard WHO audit columns), and performs the physical insert into CN_REVENUE_CLASSES. GET_UID is typically invoked beforehand so the caller supplies a valid, sequence-generated ID.
• UPDATE_ROW — the companion update procedure, allowing existing revenue class records to be modified. It applies changes to the descriptive and accounting columns of an existing row while maintaining the audit (WHO) columns for change tracking.
• DELETE_ROW — removes an existing revenue class row, subject to the usual referential and business constraints enforced by the schema.

All four routines are declared in the package specification with implementations in the body; the public API therefore consists of the insert/update/delete trio plus the ID-generation helper used internally.

Tables Accessed

The ETRM metadata records seven tables referenced through APPS synonyms:

• CN_REVENUE_CLASSES — the primary table maintained by this handler; holds one row per revenue class with its name, description, liability account, and expense account.
• CN_REVENUE_CLASSES_S — the sequence referenced by GET_UID to allocate the next revenue_class_id.
• DUAL — the single-row pseudo-table used to select the sequence value.
• CN_DIMENSIONS, CN_DIM_HIERARCHIES, CN_HEAD_HIERARCHIES, CN_HIERARCHY_NODES — the Contracts dimensions and hierarchy tables. These are referenced for validation or lookups associated with the accounting dimensions (liability and expense accounts) attached to a revenue class, or for hierarchy consistency checks performed as part of the handler logic.

Usage Notes

Because CN_REVENUE_CLASS_PKG is a table handler rather than a business API, it is normally invoked indirectly. The most common caller is the Oracle Forms UI for revenue class setup, where the form's block-level insert/update/delete triggers delegate to INSERT_ROW, UPDATE_ROW, and DELETE_ROW, and the pre-insert trigger calls GET_UID to populate the primary key. It may also be called by concurrent programs that load or migrate revenue class data, or by custom PL/SQL that needs to create revenue classes programmatically — custom code should call the packaged procedures rather than issuing direct DML to gain the sequence handling and audit-column maintenance. The ETRM metadata notes the package is referenced by one other package, confirming its role as a shared dependency within the Contracts module. As the header revision (120.2) dates to 2005, the package has remained stable across EBS 12.1.1 and 12.2.2, and no behavioral differences between those releases are documented.