Results for “cs_ctr_associations”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CS_CTR_ASSOCIATIONS is a Service (CS) module table that records the association between counter groups and inventory items. In Oracle E-Business Suite, counters and counter groups are used to track cumulative usage, meter readings, or condition-based measurements against tangible assets and inventory. This table acts as the binding layer that determines which counter groups apply to a given inventory item, enabling service organizations to define the metering profile of items that require usage or lifecycle tracking.

The ETRM metadata classifies this object as satellite-leaning under the Data Vault heuristic mined from its foreign key structure. In modeling terms, this suggests the table behaves primarily as a descriptive satellite attached to a parent entity (the counter group), rather than acting as a pure hub or an associative link. This classification is a modeling suggestion only and should be validated against the actual integration and history requirements.

Key Information Stored

The table is anchored by a surrogate primary key and one documented unique business key. The documented columns are:

• CTR_ASSOCIATION_ID — Surrogate primary key defined by the constraint CS_CTR_ASSOCIATIONS_PK. It uniquely identifies each counter group-to-item association row and is the value most commonly referenced by downstream foreign keys.
• SOURCE_OBJECT_ID — The business key column defined by the unique index CS_CTR_ASSOCIATIONS_UK1. It identifies the source object (typically the inventory item) to which a counter group is being associated, and enforces uniqueness across the association.
• COUNTER_GROUP_ID — The foreign key column referencing CS_COUNTER_GROUPS. It identifies the counter group being bound to the source object and drives the join back to the counter group definition.

Because the published metadata for this object is limited, only these three columns can be stated with certainty. Other attributes common to association tables (such as creation/update audit columns and association status flags) are not documented here and should be confirmed by querying ALL_TAB_COLUMNS in the target instance. Notably, the metadata states the table is Not implemented in this database for the reference environment, meaning it may exist in some releases and not others depending on the installed CS functionality.

Common Use Cases and Queries

Typical uses of this table include determining which counter groups are valid for a given inventory item at service-order entry, validating counter-based pricing or warranty rules, and reporting on the metering coverage of stocked items. A basic lookup joins the association to its parent group:

• Enumerate all counter groups associated with a given item: select from CS_CTR_ASSOCIATIONS where SOURCE_OBJECT_ID = :item_id, joined to CS_COUNTER_GROUPS on COUNTER_GROUP_ID.
• Resolve a counter reading back to its owning group by joining CS_CTR_ASSOCIATIONS to CS_COUNTER_GROUPS and then to counter instance tables on the resolved group.
• Audit reporting: count associations per counter group to identify groups that are over- or under-deployed across the item master.

Because SOURCE_OBJECT_ID is a unique business key, queries filtering on it can rely on a unique index scan, making per-item lookups efficient. Report writers should always constrain on either the surrogate key or the unique business key to avoid full scans on large item populations.

Related Objects

The most significant related object is the counter group parent table. The documented foreign key relationship is:

• CS_COUNTER_GROUPS — joined via CS_CTR_ASSOCIATIONS.COUNTER_GROUP_ID = CS_COUNTER_GROUPS.COUNTER_GROUP_ID. This is the primary dependency and defines the group being associated.

Beyond this documented relationship, service module objects that typically reference this association include the inventory item master (MTL_SYSTEM_ITEMS_B, resolved through SOURCE_OBJECT_ID), counter instance and reading tables within the CS counter framework, and service work-order or contract modules that evaluate counters during pricing and entitlement checks. Downstream consumers should be validated in the target instance, as the published metadata documents only the counter group foreign key and does not enumerate the full dependency graph.