Search Results csi_t_ii_relationships




Overview
Explore in AI Chat

Overview

The CSI_T_II_RELATIONSHIPS table is a core transactional data object within the Oracle E-Business Suite (EBS) Install Base (CSI) module. It serves as the staging and tracking table for all changes to relationships between tracked asset items (item instances) during business transactions. Its primary role is to record the proposed creation, update, or termination of instance-to-instance relationships as part of a pending Install Base transaction, such as a shipment, return, or configuration change. The data in this table is processed by the Install Base transaction engine to update the permanent relationship records in the CSI_II_RELATIONSHIPS table, ensuring the asset hierarchy and associations are accurately maintained.

Key Information Stored

The table's structure is designed to capture the relationship metadata and its transactional context. The primary key, TXN_RELATIONSHIP_ID, uniquely identifies each relationship change record. The core relationship is defined by the SUBJECT_ID (the parent or primary instance) and OBJECT_ID (the child or related instance), which are foreign keys to CSI_ITEM_INSTANCES. The nature of the relationship is specified by the RELATIONSHIP_TYPE_CODE, referencing the CSI_II_RELATION_TYPES table. Crucially, the TRANSACTION_LINE_ID column links the relationship change to its parent transaction line in CSI_T_TRANSACTION_LINES, while the CSI_INST_RELATIONSHIP_ID can reference an existing relationship in CSI_II_RELATIONSHIPS if the transaction is modifying or ending it. This structure allows the system to manage the complete lifecycle of instance relationships within a transactional framework.

Common Use Cases and Queries

A primary use case is troubleshooting pending transactions that affect asset structures. For example, a query to identify all relationship changes pending within a specific work order or shipment transaction would join CSI_T_II_RELATIONSHIPS to CSI_T_TRANSACTION_LINES and the master instance tables. Reporting on the proposed configuration of an asset before transaction finalization is another common scenario. Developers may query this table to validate business rules in custom extensions before submitting transactions. A typical diagnostic SQL pattern is:

  • SELECT tirl.txn_relationship_id, tirl.relationship_type_code, subj.instance_number AS subject_instance, obj.instance_number AS object_instance FROM csi_t_ii_relationships tirl JOIN csi_item_instances subj ON tirl.subject_id = subj.instance_id JOIN csi_item_instances obj ON tirl.object_id = obj.instance_id WHERE tirl.transaction_line_id = :p_txn_line_id;

Related Objects

The table is centrally connected to other key Install Base transactional and master tables through documented foreign key constraints. Its main dependencies are:

  • CSI_T_TRANSACTION_LINES: Joined via TRANSACTION_LINE_ID. This is the header-level link for the transaction.
  • CSI_ITEM_INSTANCES: Joined twice—for the SUBJECT_ID and OBJECT_ID columns—to resolve the actual item instance numbers involved.
  • CSI_T_TXN_LINE_DETAILS: Joined via SUBJECT_ID and OBJECT_ID, linking to the detailed line-level transaction records for each instance.
  • CSI_II_RELATIONSHIPS: Joined via CSI_INST_RELATIONSHIP_ID, connecting the transactional change to the target master relationship record.
  • CSI_II_RELATION_TYPES: Joined via RELATIONSHIP_TYPE_CODE, providing the valid relationship type definition.