Search Results delete_trx_types

Overview

OKL_TRX_TYPES_PUB is the public application programming interface for maintaining transaction type definitions within the Oracle Lease and Finance Management (OKL) module of Oracle E-Business Suite. The package body resides in the APPS schema and is classified as a public (PUB) API, meaning it is intended for invocation by external callers such as Oracle Forms, concurrent programs, and custom extensions. Transaction types in Oracle Lease Management govern the behaviour of lease and finance contracts, including the accounting, delinquency, and lifecycle rules applied to individual transactions. This package provides the canonical, validated entry point for creating, modifying, and removing those transaction type records so that all business rules and validations are enforced consistently regardless of the calling channel.

Key Procedures and Functions

The package exposes a small, well-defined set of documented procedures that follow the standard Oracle EBS API conventions for data manipulation and multi-language support:

• INSERT_TRX_TYPES — Creates a new transaction type record, applying the standard OKL validation and defaulting logic before the row is persisted.
• UPDATE_TRX_TYPES — Modifies an existing transaction type record, enforcing update validation rules and change-control logic.
• DELETE_TRX_TYPES — Removes a transaction type record, subject to referential and business-rule checks that prevent deletion of types in active use.
• VALIDATE_TRX_TYPES — Performs the validation checks associated with the transaction type entity, typically invoked internally by the insert, update, and delete procedures but also callable independently.
• LOCK_TRX_TYPES — Acquires a lock on the transaction type record to serialise concurrent modifications and protect against lost updates during a transaction.
• ADD_LANGUAGE — Inserts or maintains translated (multi-language) rows for transaction type descriptive attributes, supporting the multilingual requirements of a global EBS implementation.

The metadata records eleven procedures and functions in total; the six above are the explicitly documented entries. The package delegates lower-level persistence and derivation logic to the private helper package OKL_TRY_PVT and relies on the shared API infrastructure for error handling.

Tables Accessed

The documented dependency list identifies a single table reference, PLITBLM, accessed through an APPS synonym. PLITBLM is the standard Oracle PL/SQL table used in EBS for storing and processing multi-language translation rows, which aligns directly with the ADD_LANGUAGE procedure and the package's role in maintaining translated transaction type descriptions. The bulk of the transaction type data manipulation is performed indirectly through OKL_TRY_PVT, which encapsulates the base-table inserts, updates, and deletes on the transaction type entity. Callers should therefore treat the package as the interface boundary and avoid writing directly to the underlying OKL transaction type tables.

Usage Notes

OKL_TRX_TYPES_PUB is the supported integration point for transaction type maintenance in Oracle Lease and Finance Management. It is typically invoked when transaction types are defined or amended during implementation and ongoing configuration. Invocation patterns include Oracle Forms-based setup screens, concurrent programs that load or migrate transaction type data, and custom PL/SQL that needs to create or change transaction types while respecting OKL business rules. Because the package depends on FND_API and FND_MSG_PUB, callers should follow the standard EBS API calling convention: initialise the message stack, pass the standard API context, capture the returned status, and inspect the message list for errors on failure. The package is referenced by two other database objects, confirming that it participates in a wider dependency chain within the OKL module and should not be modified. Custom code should always invoke OKL_TRX_TYPES_PUB rather than manipulating the underlying tables directly, ensuring validation, locking, and language handling remain consistent across all entry points.