Search Results in_out_flag




Overview

CSI_TXN_TYPES is a reference (setup) table in the CSI — Install Base module of Oracle E-Business Suite, documented as the "Installed Base Source Transaction List." It enumerates the valid transaction types that external source applications can feed into Oracle Installed Base. Each row defines a recognized inbound or outbound transaction category — for example, an installation, a shipment, an RMA receipt, or a field service activity — and associates it with the source application that owns it. Downstream transactional records in CSI_TRANSACTIONS must resolve their TRANSACTION_TYPE_ID against this table, making CSI_TXN_TYPES the controlling vocabulary for how the Install Base engine classifies and processes inventory, order management, service, and other feeder transactions.

Under the heuristic Data Vault classification mined from its foreign key structure, this table is satellite-leaning. In modeling terms, it is best treated as a descriptive satellite carrying attributes that qualify a business key (the transaction type identifier) rather than as a pure hub or a link between two hubs. This reflects its role as a lookup-and-qualifier table whose descriptive columns (names, flags, context attributes) evolve independently of the key itself.

Key Information Stored

The table is physically owned by the CSI schema in the documented 12.2.2 dictionary and contains 32 columns. The most significant columns are:

The surrogate key is TRANSACTION_TYPE_ID, while the documented business-key candidate is the composite unique index CSI_TXN_TYPES_U01 (TRANSACTION_TYPE_ID, ZD_EDITION_NAME).

Common Use Cases and Queries

Typical uses include diagnosing failed Installed Base imports, validating whether a source system's transaction code has been registered, and building pick-lists or reports that translate transaction type IDs into readable names.

A join from transactions to their types:

  • SELECT t.transaction_id, t.transaction_type_id, y.source_txn_type_name, y.in_out_flag, y.seeded_flag FROM csi_transactions t, csi_txn_types y WHERE t.transaction_type_id = y.transaction_type_id;

Resolving the owning source application:

  • SELECT y.transaction_type_id, y.source_transaction_type, y.source_txn_type_name, a.application_short_name FROM csi_txn_types y, fnd_application a WHERE y.source_application_id = a.application_id ORDER BY a.application_short_name, y.source_txn_type_name;

To audit seeded versus custom setup, query SEEDED_FLAG = 'Y'. To trace how frequently a given type is used, aggregate CSI_TRANSACTIONS by TRANSACTION_TYPE_ID and outer-join back to CSI_TXN_TYPES to surface unused or orphaned definitions. Queries on attribute columns should always filter CONTEXT first, since DFF data is only meaningful within an assigned context.

Related Objects

The most significant related objects, based on the documented foreign key structure, are:

  • CSI_TRANSACTIONS — the primary dependent table; its TRANSACTION_TYPE_ID column references CSI_TXN_TYPES, making it the main consumer of this reference data.
  • FND_APPLICATION — referenced through CSI_TXN_TYPES.SOURCE_APPLICATION_ID (column CSI_TXN_TYPES.SOURCE_APPLICATION_ID → FND_APPLICATION) to identify the originating application.
  • FND_SECURITY_GROUPS — referenced through CSI_TXN_TYPES.SECURITY_GROUP_ID to enforce security-group partitioning.
  • CSI_TXN_TYPES_PK — the primary key constraint on TRANSACTION_TYPE_ID.
  • CSI_TXN_TYPES_U01 — the unique index on (TRANSACTION_TYPE_ID, ZD_EDITION_NAME) supporting editioned access.

Installed Base processing logic and the public CSI APIs that create or update transactions depend on this table to validate inbound transaction types before accepting them.