Search Results csi_i_version_labels_n02

Overview

The CSI.CSI_I_VERSION_LABELS table is a critical repository within the Oracle E-Business Suite (EBS) Enterprise Asset Management (EAM) and Installed Base modules. It stores version labels associated with item instances, allowing organizations to maintain a historical lineage of configuration changes, software versions, or operational states for tracked assets and inventory items. In the context of Oracle EBS 12.1.1 and 12.2.2, this table serves as the primary source for tracking the lifecycle of version information attached to a specific instance.

From a Data Vault modeling perspective, the mined metadata classifies this table as satellite-leaning. It functions effectively as a satellite table attached to the CSI_ITEM_INSTANCES hub (via the INSTANCE_ID foreign key), capturing descriptive attributes, temporal validity, and version-specific context.

Key Information Stored

This table contains 31 columns, with the most critical data elements organized around identification, versioning, and temporal tracking. The primary surrogate key is VERSION_LABEL_ID, which uniquely identifies each version label record and is supported by the unique index CSI_I_VERSION_LABELS_U01. The core business key link is INSTANCE_ID, which establishes the relationship to the parent item instance.

• VERSION_LABEL_ID: The surrogate primary key for this table, sourced from a sequence.
• INSTANCE_ID: The foreign key linking the version label to a specific instance in CSI_ITEM_INSTANCES.
• VERSION_LABEL: A descriptive string (max 30 characters) holding the actual version identifier (e.g., "V1.2", "Rev A").
• DATE_TIME_STAMP: The specific point in time associated with the version label.
• ACTIVE_START_DATE / ACTIVE_END_DATE: The effective date range defining when this version label is active for the instance.
• DESCRIPTION: A 240-character field for additional context or notes about the version.
• CONTEXT and ATTRIBUTE1–15: Standard Descriptive Flexfield (DFF) columns enabling extensible, client-specific attributes.
• SECURITY_GROUP_ID: Used for multi-tenant data security, linking to FND_SECURITY_GROUPS.
• OBJECT_VERSION_NUMBER: Supports optimistic locking for concurrent updates.
• Standard WHO Columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN for audit tracking.

Common Use Cases and Queries

This table is primarily queried for asset history reporting, compliance auditing, and configuration management. A common scenario involves retrieving the current active version label for a specific instance. This is achieved by filtering on INSTANCE_ID and checking that the current date falls between ACTIVE_START_DATE and ACTIVE_END_DATE. The non-unique index CSI_I_VERSION_LABELS_N01 on INSTANCE_ID and CSI_I_VERSION_LABELS_N02 on ACTIVE_END_DATE optimize these queries.

Sample SQL pattern:

• SELECT version_label, active_start_date, description FROM csi_i_version_labels WHERE instance_id = :p_instance_id AND SYSDATE BETWEEN NVL(active_start_date, SYSDATE-1) AND NVL(active_end_date, SYSDATE+1);

Reporting use cases include generating an audit trail of version changes per asset, analyzing downtime or version overlap intervals, and extracting DFF data (ATTRIBUTE1-15) for custom reporting. The MIGRATED_FLAG column (documented in the physical schema) supports data migration reconciliation efforts, particularly during upgrades from 12.1.1 to 12.2.2.

Related Objects

The CSI_I_VERSION_LABELS table maintains direct relationships with the following key objects:

• CSI.CSI_ITEM_INSTANCES: The parent hub table referenced by the INSTANCE_ID foreign key. Every version label must correspond to a valid item instance.
• CSI.CSI_I_VERSION_LABELS_H: The history table that references VERSION_LABEL_ID as a foreign key, capturing audit trails of changes to version labels.
• FND_SECURITY_GROUPS: Referenced by SECURITY_GROUP_ID to enforce data security for multi-org or multi-tenant access.
• CSI_ITEM_INSTANCES (via INSTANCE_ID): The primary join path for retrieving version labels alongside instance details such as item number, serial number, and location.

Additionally, APIs such as the Installed Base Public API (CSIIAPI) and EAM maintenance routines may indirectly interact with this table when processing instance updates. Understanding these relationships is essential for building accurate joins and ensuring referential integrity within custom extensions or reports.