Search Results create_color_props




Overview
Explore in AI Chat

Overview

BSC_COLOR_RANGE_PVT is a private PL/SQL package in the APPS schema that manages the color range and color property definitions used by Oracle Balanced Scorecard and related performance management components within Oracle E-Business Suite. The package encapsulates the business logic and CRUD operations for the BSC_SYS_COLOR_RANGES_B table and its related tables. Its header comment, dating from November 2006 and authored by Pradeep Pandey, describes it as a "Private Spec version" whose purpose is to "manage Range Properties properties and provide CRUD APIs for BSC_SYS_COLOR_RANGES_B and related tbl."

In the context of Oracle EBS 12.1.1 and 12.2.2, this package provides the internal implementation layer that supports the public color range API. The "PVT" classification indicates it is intended for internal use by Oracle's own application code, not as a supported integration point for customers. Color ranges are the mechanism by which scorecard KPIs and objectives are visually graded—for example, assigning red, yellow, or green status bands based on threshold values—and this package manages the metadata that drives that behavior.

Key Procedures and Functions

The ETRM documentation identifies four documented procedures in this package:

  • CREATE_COLOR_PROPS — Creates color property records. This procedure associates a property value with a given objective, KPI measure, color type, and color range, effectively defining the individual color attributes attached to a range definition.
  • CREATE_COLOR_RANGE — Creates a color range definition. It accepts a range identifier and a color range record structure, along with the user identifier, and persists the new range to the underlying tables.
  • DELETE_COLOR_RANGES — Removes color range definitions. This is the delete counterpart to the creation API, used when a range definition is no longer required or is being replaced.
  • DELETE_COLOR_PROP_RANGES — Removes the associations between color properties and ranges. This supports cleanup of property-range linkages, which is necessary before a range or property can be safely removed.

All four procedures follow standard Oracle EBS API conventions, as evidenced by the header signatures: a p_commit parameter defaulting to FND_API.G_FALSE, and the standard x_return_status, x_msg_count, and x_msg_data OUT parameters used for error handling and message propagation through the FND message stack. The source header also records a 2007 bug fix (Bug#6132361) for PL/SQL objective handling.

Tables Accessed

The package references the following tables through APPS synonyms:

  • BSC_COLOR_RANGES — The primary table storing color range definitions. This is the central object managed by the create and delete range procedures.
  • BSC_COLOR_TYPE_PROPS — Stores properties associated with color types, supporting the property creation and property-range association logic.
  • FND_USER — Used to validate and record the user identifier associated with range creation, supporting standard EBS auditing conventions.
  • PLITBLM — The standard PL/SQL message table used by the FND message-handling framework to accumulate and retrieve error and warning messages.

Usage Notes

Because this package is classified as PVT, it is not a supported public API and should not be called directly by customer customizations. It is typically invoked by the Balanced Scorecard application layer—most commonly through the public BSC_COLOR_RANGES_PUB package or from Oracle Forms-based scorecard configuration screens—whenever a user defines or modifies color ranges and their associated properties. The metadata indicates the package is referenced by one other package, consistent with its role as an internal dependency behind a public wrapper. Developers maintaining or troubleshooting scorecard color configuration should treat BSC_COLOR_RANGE_PVT as an implementation detail: it may change between releases, and any direct dependency on its procedures carries upgrade risk. Where customization is required, the documented public APIs and supported extension mechanisms should be used instead.