Search Results service_contract_id

Overview

OKL_CS_TRX_CONTRACTS_UV is a read-only database view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKL – Leasing and Finance Management module. Its documented purpose is to display Service Contracts, presenting a consolidated projection of service-related transaction and contract header information sourced from the leasing transaction tables. The view is registered as VALID in the ETRM metadata and is available in both Oracle EBS 12.1.1 and 12.2.2 environments.

The view serves as a reporting and integration surface rather than a transactional object. Because it joins lease transaction data with Oracle Application Object Library lookup values, it allows downstream reports, concurrent programs, and external interfaces to retrieve human-readable transaction status descriptions without re-implementing the join logic against FND_LOOKUPS. The inclusion of the TRANSACTION_TYPE_DESC column—derived from FND_LOOKUPS.MEANING—makes the view particularly useful for users searching on transaction type descriptions, since the stored transaction type code is decoded into its descriptive meaning automatically.

Underlying Base Objects

The documented base objects referenced by OKL_CS_TRX_CONTRACTS_UV are:

• OKL_TRX_CONTRACTS (accessed via synonym) — the primary source of transaction and contract records.
• FND_LOOKUPS (view) — supplies lookup meaning values used to translate codes into descriptions.
• FND_GLOBAL (package) — a standard Applications foundation package referenced in the view's definition, typically used for session and context resolution such as organizational or user context.

The view text joins OKL_TRX_CONTRACTS to FND_LOOKUPS on a composite condition: only rows where TCN_TYPE = 'SER' (service contracts) are returned, the lookup type is constrained to 'OKL_TRANSACTION_STATUS', and TRX.TSU_CODE is matched to LOOKUP.LOOKUP_CODE. This effectively filters the underlying transaction table to service contract transactions while enriching each record with its status meaning. The relationship to OKL_TRX_CONTRACTS is therefore one of direct dependency—every row in the view corresponds to a qualifying transaction row in that table.

Key Columns

• HEADER_CONTRACT_ID (mapped from TRX.KHR_ID) — identifier of the header-level contract record.
• TRANSACTION_DATE (from TRX.DATE_TRANSACTION_OCCURRED) — the date on which the transaction occurred.
• TRANSACTION_TYPE_CODE (from TRX.TSU_CODE) — the stored status/transaction code.
• TRANSACTION_TYPE_DESC (from FND_LOOKUPS.MEANING) — the decoded, human-readable description of the transaction type. This is the column most relevant to searches on transaction type description.
• TRANSACTION_NUMBER (from TRX.TRX_NUMBER) — the transaction number; the view result is ordered by this column in descending sequence.
• SERVICE_CONTRACT_ID (from TRX.CHR_ID) — identifier of the associated service contract.
• TRX_DESCRIPTION (from TRX.DESCRIPTION) — free-text description of the transaction.
• TRX_ID (from TRX.ID) — primary identifier of the transaction record.
• TRY_ID (from TRX.TRY_ID) — secondary identifier carried through from the transaction table.

Common Use Cases and Queries

Typical scenarios include reporting on service contract transactions by status description, reconciling lease transactions against their lookup meanings, and feeding external systems with decoded transaction data. A common query retrieves recent service contract transactions with descriptive status values:

• SELECT transaction_number, transaction_date, transaction_type_desc, service_contract_id FROM okl_cs_trx_contracts_uv WHERE transaction_type_desc = 'Active' ORDER BY transaction_date DESC;
• SELECT header_contract_id, trx_id, trx_description FROM okl_cs_trx_contracts_uv WHERE service_contract_id = :contract_id;

Because the view filters on TCN_TYPE = 'SER', queries automatically exclude non-service transaction types, simplifying report logic. Callers should rely on TRANSACTION_TYPE_DESC for presentation and on TRANSACTION_TYPE_CODE for programmatic joins, since lookup meanings can be changed by application users.