Search Results cn_revenue_class_pkg




Overview
Explore in AI Chat

Overview

CN_REVENUE_CLASS_PKG is the table handler package for the CN_REVENUE_CLASSES entity within the Oracle E-Business Suite Enterprise Contracts (formerly Telecommunications Billing / Revenue Management) module. Its header declares AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking schema rather than the owning APPS schema. The package encapsulates the data manipulation logic required to maintain revenue class definitions — the classification records used to categorize contract revenue lines and to associate them with the appropriate liability and expense accounting accounts. By centralizing insert, update, and delete operations in a single package, the contracts module ensures that revenue class records are created and maintained consistently, that surrogate keys are generated correctly, and that the audit columns (WHO columns) and multi-organization context (ORG_ID) are populated uniformly. The package is classified in the ETRM metadata as OTHER, indicating it is a server-side utility module rather than a public, externally versioned API.

Key Procedures and Functions

The package exposes three documented procedures, all of which follow the standard Oracle Forms-style table handler pattern.

  • INSERT_ROW — The main insert procedure for creating a new revenue class record. It accepts the revenue class identifier as an IN OUT NOCOPY parameter, allowing the generated primary key to be returned to the caller. It also takes the descriptive attributes (name and description), the liability and expense account identifiers, the standard WHO audit columns, and the ORG_ID for organization-level partitioning.
  • UPDATE_ROW — Updates an existing revenue class record. It accepts the revenue class identifier together with the mutable attributes, and defaults each parameter to the FND_API.G_MISS_* sentinel values so that only explicitly supplied columns are changed. It also accepts an object version number for optimistic locking plus the WHO audit columns.
  • DELETE_ROW — Removes a revenue class record identified by its primary key.

No functions are declared in the documented specification. The specification carries a header comment dating to the original 02-Feb-2001 creation by Kumar Sivasankaran, with a later revision in 2005.

Tables Accessed

The ETRM metadata lists the following tables as accessed through APPS synonyms:

  • CN_REVENUE_CLASSES and CN_REVENUE_CLASSES_S — the base and translated (or secondary) tables that store the revenue class definitions this package maintains. These are the primary write targets of INSERT_ROW, UPDATE_ROW, and DELETE_ROW.
  • CN_DIMENSIONS, CN_DIM_HIERARCHIES, CN_HEAD_HIERARCHIES, CN_HIERARCHY_NODES — the contracts dimension and hierarchy tables. These are referenced because revenue classes participate in the contracts dimension model, where classes are associated with hierarchy structures for reporting and revenue allocation.
  • DUAL — the standard Oracle single-row utility table, typically used for sequence value retrieval or validation queries.

Because table handler packages typically validate foreign key relationships, the dimension and hierarchy tables are read to confirm that referenced account and hierarchy values are valid before a revenue class is persisted.

Usage Notes

CN_REVENUE_CLASS_PKG is an internal table handler rather than a published integration API. It is most commonly invoked from the Enterprise Contracts setup forms and from the Contracts-related concurrent programs that seed or migrate revenue class configuration. Because the procedures default many parameters to FND_API.G_MISS_* values (particularly in UPDATE_ROW), the package is designed to be called from Oracle Forms, where unspecified form fields are passed as sentinels and only changed columns are propagated to the database. The metadata also records that the package is referenced by one other package, indicating server-side reuse within the contracts module. Custom extensions should generally avoid calling this package directly in favor of supported public APIs, but where direct data maintenance is required, the standard WHO audit columns and ORG_ID must be supplied to preserve multi-organization and audit integrity.