Search Results get_rate_table_name

Overview

CN_API is the foundational utility package within the Oracle E-Business Suite Incentive Compensation (CN) module, classified by ETRM as a public API and owned by the APPS schema. It is defined with AUTHID CURRENT_USER, meaning its database objects and privileges are resolved in the context of the calling session rather than the package owner. While the name suggests a business-facing application interface, the 12.1.1 source header (cnputils.pls) reveals that CN_API functions primarily as a shared internal utilities and validation library for the Incentive Compensation schema — the "cnp utils" naming confirms this role. It centralizes low-level tasks that dozens of other CN packages depend upon: reading and propagating the Oracle Forms/FND message stack, translating surrogate identifiers into human-readable names, and enforcing standard null/mandatory validation rules on procedure parameters. The package is referenced by approximately 132 other packages in the 12.2.2 ETRM repository, establishing it as one of the most widely consumed dependencies in the Incentive Compensation codebase.

Key Procedures and Functions

The documented 83 subprograms fall into several functional groups. The user query chk_miss_num_para targets the parameter-validation family, which includes:

• CHK_MISS_NUM_PARA, CHK_MISS_CHAR_PARA, CHK_MISS_DATE_PARA — verify that a mandatory parameter of numeric, character, or date datatype has been supplied, raising an appropriate error when it is absent.
• CHK_NULL_NUM_PARA, CHK_NULL_CHAR_PARA, CHK_NULL_DATE_PARA — confirm that a given numeric, character, or date parameter is null where nulls are expected.
• CHK_MISS_NULL_NUM_PARA, CHK_MISS_NULL_CHAR_PARA, CHK_MISS_NULL_DATE_PARA — combined checks that handle both the "missing" and "must be null" conditions for each datatype.
• PE_NUM_FIELD_MUST_NULL, PE_CHAR_FIELD_MUST_NULL, PE_NUM_FIELD_CANNOT_NULL — related field-level enforcement helpers used during parameter establishment/validation flows.

Data-translation helpers include GET_RATE_TABLE_NAME and GET_RATE_TABLE_ID (bidirectional lookup between a rate schedule name and its surrogate ID, the latter scoped by organization), GET_PERIOD_NAME and GET_PERIOD_ID (period translation with a restriction to open periods), GET_REV_CLASS_ID and GET_REV_CLASS_NAME (revenue class conversion), and GET_LKUP_MEANING (retrieval of lookup meanings). GET_FND_MESSAGE reads from the FND message stack, flushes the CN message stack, and copies messages across; notably, it issues an internal COMMIT, a behavior callers must account for.

Tables Accessed

Table access is performed through APPS synonyms. CN_RATE_SCHEDULES supports the rate-table name/ID translation functions. CN_REVENUE_CLASSES underpins revenue class lookups. GL_CODE_COMBINATIONS is referenced for code combination handling, including the CODE_COMBINATION_REC record structure. The remaining documented tables — CN_CALC_FORMULAS, CN_COMMISSION_LINES, CN_COMP_PLANS, CN_CREDIT_TYPES, CN_PMT_PLANS, CN_QUOTA_ASSIGNS, CN_ROLE_PLANS, CN_ROLE_PMT_PLANS, CN_SRP_PAYEE_ASSIGNS, CN_ATTRIBUTE_RULES, and the _ALL variants of CN_CALC_FORMULAS and CN_COMP_PLANS — reflect the package's role as a shared validator and lookup layer spanning the core Incentive Compensation configuration and transaction model, including multi-organization (_ALL) access.

Usage Notes

CN_API is typically invoked indirectly rather than called by end users. Oracle Forms-based Incentive Compensation setup screens call the validation routines to enforce mandatory and null constraints before DML is executed, and the message-stack utilities coordinate error display via GET_FND_MESSAGE. Concurrent programs and other CN batch packages similarly rely on the translation functions (period, rate table, revenue class, lookup) to resolve IDs to display values and vice versa. Custom extensions and 132 downstream packages consume the same public subprograms, which is why the package is classified as an API. Developers should note the internal COMMIT within GET_FND_MESSAGE when calling it from transactional code, and should prefer the package's standard CHK_* validators over re-implementing null checks to preserve consistent error messaging across Incentive Compensation.