Search Results cleanup_pool_contents

Overview

OKL_POOL_PUB is the public (PUB) API package for the Oracle Lease and Finance Management (OKL) "pool" entity within Oracle E-Business Suite. A pool in the OKL schema represents a grouping construct used to aggregate lease contracts, assets, or related financial records for downstream processing — for example, for investor funding, syndication, or portfolio-based accounting. The package body exposes a thin, standardized public wrapper over the corresponding private package, OKL_POOL_PVT, and is classified as a PUB API, meaning it is intended for external consumption by Forms, concurrent programs, and custom extensions rather than being called internally by other OKL packages.

The source header records a version of $Header: OKLPSZPB.pls 120.0 2007/07/27, indicating the package has been stable since early release 12 development and is carried forward unchanged into 12.1.1 and 12.2.2. The package follows the canonical Oracle EBS PL/SQL API pattern: private implementation in a _PVT package, public published interface in a _PUB package, with OKL_API providing shared return-status constants, message handling, and exception values.

Key Procedures and Functions

The documented public interface exposes four procedures:

• CREATE_POOL — Creates a new pool record. This is the entry point used when an operator or program needs to establish a pool header and its associated attributes. The excerpt shows it accepts a version identifier, an initialization flag for the messaging stack, standard OUT return status, message count, and message data parameters, plus an IN/OUT record of type polv_rec_type carrying the pool attributes. The body sets a savepoint (trx_create_pool), delegates to OKL_Pool_Pvt.create_pool, propagates return status by raising OKL_API.G_EXCEPTION_ERROR or G_EXCEPTION_UNEXPECTED_ERROR, and rolls back to the savepoint on failure while populating messages via FND_MSG_PUB.count_and_get.
• UPDATE_POOL — Modifies an existing pool, using the same polv_rec_type record structure and the same error/rollback conventions as CREATE_POOL. This is the procedure most directly relevant to users searching for "update_pool," since it is the sanctioned API for programmatic changes to pool data rather than direct DML.
• CLEANUP_POOL_CONTENTS — Removes or resets the contents associated with a pool, presumably freeing its member assignments (contracts, assets, or lines) while retaining the pool header.
• ADD_POOL_CONTENTS — Adds new members to an existing pool, complementing CLEANUP_POOL_CONTENTS. Together these two procedures allow incremental maintenance of pool membership without recreating the pool.

Tables Accessed

The ETRM metadata for this package does not enumerate tables accessed via APPS synonyms. Because the public API delegates all work to OKL_POOL_PVT, the base tables are owned by the private package. In practice these will be the OKL pool header and pool contents tables (OKL_POOLS and its child detail tables), which store pool definitions and their member records. Callers should not assume any direct table access from OKL_POOL_PUB; all persistence is performed behind the private API boundary, which is a deliberate encapsulation decision.

Usage Notes

OKL_POOL_PUB is not referenced by any other package in the E-Business Suite, confirming it is a top-level entry point. Typical invocation patterns are:

• From Oracle Forms (the OKL Pool maintenance form) via a database block or button trigger, passing the current form record as polv_rec_type.
• From concurrent programs or custom PL/SQL that need to create, update, or restructure pools in bulk.
• From external integrations or extensions that must honor the OKL API contract rather than writing directly to pool tables.

Callers must always check x_return_status against OKL_API.G_RET_STS_SUCCESS, inspect x_msg_count and x_msg_data, and never issue an unqualified COMMIT before verifying success. Because each procedure opens its own savepoint and rolls back on error, the API participates correctly in a larger transactional unit. Direct DML against the underlying pool tables is strongly discouraged, as it bypasses the validation and message-handling logic implemented in OKL_POOL_PVT.