Search Results get_transactions

Overview

APPS.CSI_TRANSACTIONS_PVT is a private (PVT) PL/SQL package in the Oracle E-Business Suite Install Base / Enterprise Asset Management (CSI) product family. It provides the core transactional engine for Install Base transaction records — the electronic record of a change of ownership, location, status, or configuration of an installed instance or asset. The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the calling schema and relies on APPS synonyms for its underlying data objects.

The header of the source file dates from the 11.5.x code line ($Header: csivtrxs.pls 115.14 ...) and the package remains present and callable in both 12.1.1 and 12.2.2. Its two primary responsibilities are (1) the querying and paging of existing Install Base transactions, and (2) the creation and maintenance of transaction records, including validation of API inputs and standardized error capture. Because the package is classified as private, Oracle does not document it as a supported public interface; it is intended for internal consumption by other CSI modules and by public (PUB) wrapper APIs such as CSI_TRANSACTIONS_PUB.

Key Procedures and Functions

• GET_TRANSACTIONS — The procedure most commonly sought by the search term "get_transactions." It accepts a transaction query record (p_txnfind_rec) that acts as a dynamic search filter, a paging size (p_rec_requested, defaulting to the package constant g_default_num_rec_fetch = 30), a start record pointer, and an optional sort record (p_order_by_rec) built from the util_order_by_rec_type structure. It returns a table of transaction header records (x_transaction_tbl) along with status codes, message count and data, the number of records returned, the next record pointer for continuation, and an optional total record count. It follows the standard FND_API calling convention with an API version number, message list initialization flag, commit flag, and validation level.
• CREATE_TRANSACTION — Accepts and validates parameters before inserting the corresponding row into the CSI_TRANSACTIONS table. It adheres to the same FND_API parameter conventions (version, message list, commit, validation level) used by GET_TRANSACTIONS.
• UPDATE_TRANSACTIONS — Provides the update counterpart to CREATE_TRANSACTION, applying validated changes to existing transaction records in CSI_TRANSACTIONS.
• CREATE_TXN_ERROR — A supporting routine that records standardized error information for a transaction, allowing failures encountered during processing to be persisted and reported.

Tables Accessed

• CSI_TRANSACTIONS — The primary transaction table; read by GET_TRANSACTIONS and written by CREATE_TRANSACTION and UPDATE_TRANSACTIONS.
• CSI_TXN_TYPES — Defines the valid transaction types that a transaction record may reference; used for validation during creation and update.
• FND_USER — Supplies the application user identity associated with a transaction for auditing and ownership purposes.
• JTF_OBJECT_USAGES — The CRM/Foundation object-usage registry used to associate Install Base transactions with the correct object usage context.
• DUAL and DBMS_SQL — DUAL is used for scalar evaluations and housekeeping selects; DBMS_SQL indicates that the package builds dynamic SQL, consistent with the configurable ORDER BY and filter criteria accepted by GET_TRANSACTIONS.

Usage Notes

CSI_TRANSACTIONS_PVT is normally invoked indirectly. The documented metadata records that it is referenced by 28 other packages, so any change to its signatures or behavior carries broad impact across the Install Base and asset modules. The typical callers are the corresponding public API layer (CSI_TRANSACTIONS_PUB), Install Base forms that display or page through transaction history, and concurrent programs that process or report on transactions in bulk.

Custom code should prefer the public wrapper APIs. Where direct calls to CSI_TRANSACTIONS_PVT are unavoidable, developers must honor the FND_API contract: pass a valid p_api_version_number, check x_return_status against fnd_api.g_ret_sts_success, iterate the message stack when a failure occurs, and manage commit behavior explicitly via p_commit. For GET_TRANSACTIONS, callers should loop using x_next_rec_ptr as the subsequent p_start_rec_prt until x_returned_rec_count is zero, since the procedure returns paged result sets rather than the full set in a single call.