Search Results csi_transactions




Overview
Explore in AI Chat

Overview

The CSI_TRANSACTIONS table is the central transaction log for Oracle E-Business Suite's Install Base (CSI) module in versions 12.1.1 and 12.2.2. It functions as an audit trail, recording every significant event or change that occurs to an installed product instance. This includes actions such as installations, updates, movements, merges, and terminations. The table's primary role is to provide a historical, immutable record of all transactional activity, enabling traceability, audit compliance, and support for complex business processes like warranty tracking, service history, and asset lifecycle management. Each record in this table represents a single, discrete transaction applied to the Install Base.

Key Information Stored

The table's structure is designed to capture the essential metadata of a transaction. Its primary key is TRANSACTION_ID, a unique identifier for each logged event. A critical foreign key is TRANSACTION_TYPE_ID, which links to the CSI_TXN_TYPES table to classify the nature of the transaction (e.g., 'CREATE', 'UPDATE', 'MOVE'). While the provided metadata does not list all columns, typical columns in such a transaction log would include timestamps (CREATION_DATE, LAST_UPDATE_DATE), the identifier of the user or concurrent program that initiated the transaction (CREATED_BY, LAST_UPDATED_BY), and references to the source document that triggered the transaction, such as a Work Order or Sales Order number. The core transactional data itself (the before and after state of the instance) is stored in the various history tables that reference CSI_TRANSACTIONS via foreign key.

Common Use Cases and Queries

A primary use case is auditing and reporting on the complete service history of a specific item instance. Support personnel can trace all modifications to diagnose issues or verify configuration changes. Financial and service teams use this data to validate warranty coverage or service contract entitlements based on installation and update dates. A common reporting pattern involves joining CSI_TRANSACTIONS to CSI_ITEM_INSTANCES_H and CSI_TXN_TYPES. For example, to find all update transactions for a specific instance:

  • SELECT ct.transaction_id, ctt.name txn_type, cih.instance_number, ct.creation_date
  • FROM csi_transactions ct,
  • csi_txn_types ctt,
  • csi_item_instances_h cih
  • WHERE ct.transaction_type_id = ctt.transaction_type_id
  • AND cih.transaction_id = ct.transaction_id
  • AND cih.instance_id = <INSTANCE_ID>
  • AND ctt.name = 'UPDATE'
  • ORDER BY ct.creation_date DESC;

Another critical use is troubleshooting failed transactions by joining to the CSI_TXN_ERRORS table to analyze error logs associated with a specific TRANSACTION_ID.

Related Objects

As the foundational transaction log, CSI_TRANSACTIONS is referenced by numerous Install Base history tables, which store the actual changed attribute data for each transaction. Key dependent history tables, as per the foreign key metadata, include:

  • CSI_ITEM_INSTANCES_H: Historical changes to item instance core attributes.
  • CSI_I_ASSETS_H: Historical changes to associated asset information.
  • CSI_I_PARTIES_H: Historical changes to party assignments (e.g., owner, installer).
  • CSI_I_ORG_ASSIGNMENTS_H: Historical changes to organization assignments.
  • CSI_II_RELATIONSHIPS_H: Historical changes to instance-to-instance relationships.
  • CSI_SYSTEMS_H: Historical changes to system (parent instance) definitions.
  • CSI_TXN_ERRORS: Logs errors associated with a transaction for debugging.

The table is governed by the CSI_TXN_TYPES lookup table, which defines the valid transaction types. Transactional integrity is maintained through the primary key constraint CSI_TRANSACTIONS_PK.