Search Results cs_ctr_formula_bvars




Overview
Explore in AI Chat

Overview

CS_CTR_FORMULA_BVARS is a table in the CS (Service) product schema of Oracle E-Business Suite, present in both release 12.1.1 and 12.2.2. The object carries a status of VALID in the ETRM data dictionary, and its physical schema is documented with 29 columns and an owner of CS. The most significant characteristic recorded in the metadata is the descriptive statement "This table is not used." Despite this, the table persists in the delivered schema with a complete column set, indexes, and foreign key constraints, which is consistent with a legacy or superseded structure retained for schema compatibility rather than active application logic.

From a relational modeling perspective, the heuristic Data Vault classification for CS_CTR_FORMULA_BVARS is a link, derived from its foreign key structure. This suggests the table historically served as an associative entity connecting two instances of the CS_COUNTERS entity through the columns COUNTER_ID and MAPPED_COUNTER_ID, with BIND_VAR_NAME providing a qualifying or naming attribute for the association. Under this modeling interpretation, the table would have recorded the mapping between a counter and a mapped counter, together with a bind variable name used in a formula context. The presence of MAPPED_INV_ITEM_ID and READING_TYPE among the documented columns further indicates the original design intent related counter bindings to inventory items and reading semantics.

Key Information Stored

The table's documented columns include surrogate, business, and standard EBS audit attributes. The most important entries are:

The existence of two distinct unique indexes (U1 on the surrogate key, UK1 and UK2 on business combinations) confirms that the table was designed with enforced business uniqueness rules in addition to the surrogate identifier.

Common Use Cases and Queries

Because the table is documented as unused, it should not appear in functional reporting for current implementations. Practical interaction is limited to schema inspection, upgrade impact analysis, and confirming that no custom code or concurrent program references it. A typical diagnostic query to verify whether any data has been written is:

  • SELECT COUNT(*) FROM CS.CS_CTR_FORMULA_BVARS; — confirm whether the table contains rows in a given environment.
  • SELECT CTR_FORMULA_BVAR_ID, COUNTER_ID, BIND_VAR_NAME, MAPPED_COUNTER_ID FROM CS.CS_CTR_FORMULA_BVARS ORDER BY CTR_FORMULA_BVAR_ID; — inspect legacy rows where present.

Join-based validation against the referenced entities follows the foreign keys, for example joining CS_COUNTERS on COUNTER_ID and again on MAPPED_COUNTER_ID to resolve both sides of the historical mapping. For reporting purposes, the recommended approach is to derive equivalent information from actively maintained counter and formula tables rather than relying on this structure.

Related Objects

The relationship data identifies the following significant dependencies through foreign keys and indexes:

  • CS_COUNTERS — referenced twice: CS_CTR_FORMULA_BVARS.COUNTER_ID → CS_COUNTERS and CS_CTR_FORMULA_BVARS.MAPPED_COUNTER_ID → CS_COUNTERS. This dual reference is the basis for the link classification.
  • FND_SECURITY_GROUPS — referenced by CS_CTR_FORMULA_BVARS.SECURITY_GROUP_ID, providing the security grouping used across EBS data.
  • CS_CTR_FORMULA_BVARS_PK — the primary key constraint, in addition to unique indexes CS_CTR_FORMULA_BVARS_U1, CS_CTR_FORMULA_BVARS_UK1, and CS_CTR_FORMULA_BVARS_UK2.

No APIs, views, or additional dependent tables are documented for this object in the ETRM metadata. Any integration work should therefore treat CS_CTR_FORMULA_BVARS as a dormant legacy structure and confirm against the target release whether it remains populated before building queries against it.