Search Results okl_version_pvt




Overview
Explore in AI Chat

Overview

OKL_VERSION_PVT is a private (PVT) PL/SQL package in the Oracle E-Business Suite Applications (APPS) schema that supports versioning of Oracle Lease Management (OKL) contracts. It belongs to the Oracle Enterprise Trading and Risk Management (ETRM) product family and is delivered under the 12.1.1 and 12.2.2 code lines. The package operates with AUTHID CURRENT_USER and is declared in the header as a private implementation unit, meaning it is intended for internal use by other OKL packages rather than direct invocation by end users or external integrations.

The central business purpose of OKL_VERSION_PVT is to manage the version lifecycle of a contract header identified by p_chr_id. Contract versioning allows Lease Management users to snapshot, discard, and reinstate contract states without losing the underlying contractual history. Because this functionality underpins contract revision control, the package interacts with both the core contract tables (OKC_*) and the lease-specific extension tables (OKL_*), ensuring that header, line, asset, and status information remain consistent across version operations.

Key Procedures and Functions

The package exposes four documented procedures, each following the standard EBS API parameter conventions (API version, initialization flag, return status, message count, and message data):

  • VERSION_CONTRACT — Creates a new version of a contract. It accepts a migration/version record type (cvmv_rec_type, a subtype of OKL_OKC_MIGRATION_PVT.CVMV_REC_TYPE) as input and returns the same record type, allowing the caller to pass and receive structured context for the versioning operation.
  • SAVE_VERSION — Saves the current state of a contract as a retrievable version. This is the procedure most commonly associated with the "save_version" search term. It operates against a contract header identified by p_chr_id and supports optional commit control via p_commit.
  • ERASE_SAVED_VERSION — Removes a previously saved version for the specified contract header, discarding the snapshot while leaving the active contract intact.
  • RESTORE_VERSION — Restores a contract to a previously saved version, effectively rolling the contract state back to the captured snapshot.

Tables Accessed

Examination of the package metadata identifies broad access across contract and lease data structures via APPS synonyms. Header-level data is read and written in OKC_K_HEADERS_B, OKL_K_HEADERS, and OKL_K_HEADERS_H. Line-level data is handled through OKC_K_LINES_B, OKL_K_LINES, and OKL_K_LINES_H. Version numbering is persisted in OKC_K_VERS_NUMBERS_H, which is the principal table recording contract version identifiers.

Supporting reference tables include OKC_SUBCLASS_TOP_LINE, OKC_LINE_STYLES_B and OKC_STATUSES_B, which supply line classification and status values. Asset-related content is captured through OKL_CONTRACT_ASSET_H, OKL_CONTRACT_IB_H, and FA_ADDITIONS_B, reflecting the linkage between lease contracts and fixed assets. Supplier invoice detail data is retained in OKL_SUPP_INVOICE_DTLS_H. Together these tables allow versioning to preserve a complete contract picture rather than only the header record.

Usage Notes

OKL_VERSION_PVT is a private API and is not intended to be called directly from custom code or concurrent programs. It is invoked internally as part of the OKL contract authoring and maintenance flow, and EBS metadata records that it is referenced by two other packages within the OKL module. Calls to the save, erase, and restore version operations typically originate from the Lease Management contract entry forms (for example, the contract versioning and revision user exits), where user actions such as "Save Version" trigger the underlying SAVE_VERSION routine.

Developers extending OKL functionality should prefer public APIs and documented extension points over calling this package directly, since the private designation signals that signatures may change between releases. When p_commit is left at its default of OKL_API.G_FALSE, the calling transaction retains control of commit boundaries, which is important when version operations are combined with other DML in a single logical transaction. Callers should always inspect x_return_status and the message stack (x_msg_count, x_msg_data) for error handling.