Search Results cs_transactions

Overview

The CSI_IB_TXN_TYPES table is a core configuration table within the Oracle E-Business Suite Installed Base (CSI) module, present in both releases 12.1.1 and 12.2.2. It functions as a master reference that defines and controls the behavior of different transaction types that can be performed on installed base items. The table establishes a critical link between Service Transaction Types (from the CS_TRANSACTIONS table) and specific Installed Base processing logic. Its primary role is to govern the business rules and mandatory actions—such as ownership changes, status updates, and instance referencing—that must be executed when a corresponding service transaction is processed against an item instance in the installed base.

Key Information Stored

The table's columns define the rules for source and non-source instances involved in a transaction. The key identifier columns are SUB_TYPE_ID (the primary key for the IB transaction type) and CS_TRANSACTION_TYPE_ID (the foreign key to the service transaction type). The IB_TXN_TYPE_CODE classifies the transaction using a lookup. The remaining columns are predominantly flags and reference IDs that dictate processing requirements:

• SRC_REFERENCE_REQD, NON_SRC_REFERENCE_REQD: Flags ('Y'/'N') mandating if a source or other instance must be referenced.
• SRC_CHANGE_OWNER, NON_SRC_CHANGE_OWNER: Flags indicating if ownership of the instance must be changed.
• SRC_CHANGE_OWNER_TO_CODE, NON_SRC_CHANGE_OWNER_TO_CODE: Target ownership codes (e.g., INTERNAL, EXTERNAL).
• SRC_STATUS_ID, NON_SRC_STATUS_ID: The target status to apply to the instance post-transaction.
• SRC_RETURN_REQD, SRC_REVISION_REQD: Flags for return and revision requirements on the source instance.

Common Use Cases and Queries

This table is central to validating and driving the backend logic for transactions like repairs, returns, swaps, and ownership transfers. A common use case is to retrieve the complete rule set for a specific service transaction to validate if a user's action complies with defined business rules before processing. For reporting and troubleshooting, administrators often query this table to understand the configured behavior for all transaction types.

Sample Query: To list all configured transaction types with their key rules:

SELECT ibtt.ib_txn_type_code,
       ibtt.src_reference_reqd,
       ibtt.src_change_owner_to_code,
       cst.transaction_type_id
FROM   csi.csi_ib_txn_types ibtt,
       cs.cs_transaction_types_vl cst
WHERE  ibtt.cs_transaction_type_id = cst.transaction_type_id
ORDER BY ibtt.ib_txn_type_code;

Another critical pattern is joining to the CSI_ITEM_INSTANCES table via transaction interface tables to enforce these rules during transaction submission.

Related Objects

The CSI_IB_TXN_TYPES table has defined relationships with several key EBS objects, primarily through foreign key constraints:

• CS_TRANSACTION_TYPES (via CS_TRANSACTION_TYPE_ID): This is the most direct relationship, linking the IB transaction rules to a specific Service Management transaction type. The column CS_TRANSACTION_TYPE_ID in CSI_IB_TXN_TYPES references the transaction type identifier in the CS_TRANSACTIONS (or related) entity.
• Lookup Codes (CSI_IB_TXN_TYPE_CODE): The IB_TXN_TYPE_CODE column typically references a lookup type (e.g., CSI_IB_TXN_TYPE) to provide a user-friendly transaction classification.
• CSI_INSTANCE_STATUSES (via SRC_STATUS_ID, NON_SRC_STATUS_ID): These columns are foreign keys to the CSI_INSTANCE_STATUSES table, defining the precise status to set on an instance after the transaction is processed.
• Transaction Processing Logic: While not a direct foreign key, this table is extensively referenced by the Installed Base transaction engine (likely within packages like CSI_TRANSACTION_PUB) which reads these rules to execute instance updates.