Search Results update_mass_rbk_contract

Overview

OKL_MASS_REBOOK_PUB is the public API layer of the Oracle Lease Management (OKL) mass rebook process, delivered as part of the Oracle E-Business Suite 12.1.1 and 12.2.2 release streams. The package supports the bulk rebooking of lease and loan contracts, a business operation in which a large population of contracts is re-evaluated against a revised accounting book or set of financial parameters and then rebooked in a single controlled run rather than through individual contract maintenance.

The header identifies this as a public (_PUB) API package with the constant G_PKG_NAME set to OKL_MASS_REBOOK_PUB and G_API_TYPE set to _PUB, confirming that procedures are intended for external invocation by concurrent programs, forms, and custom extensions. The package body is registered in APPS with the file identifier OKLPMRPB.pls, version 115.5. Global variables such as G_DEBUG and G_INIT_NUMBER control diagnostics and sentinel values used across the internal logic.

The central design pattern is a two-phase model: a selection phase that identifies the contracts to be rebooked, and a processing phase that applies the rebook to the selected population. Selection criteria captured in OKL_MASS_RBK_CRITERIA drive dynamic SQL that populates the work table OKL_RBK_SELECTED_CONTRACT, after which each selected contract is processed. This architecture allows a single submission to rebook many contracts while retaining an auditable selection list.

Key Procedures and Functions

The package exposes six documented procedures and functions. They are conventionally divided between selection and execution.

• BUILD_AND_GET_CONTRACTS — Builds the contract selection set using dynamic SQL derived from the criteria stored in OKL_MASS_RBK_CRITERIA for a given request name, inserts the resulting contract information into OKL_RBK_SELECTED_CONTRACT, and returns the selected contracts along with a rebook count.
• PROCESS_MASS_REBOOK — Coordinates the mass rebook run, driving the selected contracts through the rebooking logic.
• APPLY_MASS_REBOOK — Applies the rebook changes to the population of contracts identified by the preceding selection step.
• UPDATE_MASS_RBK_CONTRACT — Updates the mass rebook contract record, maintaining the status and control information associated with the selected contract within the mass rebook work area. This is the procedure most commonly referenced when users search for update_mass_rbk_contract.
• MASS_REBOOK_AFTER_YIELD — Handles the rebook activity performed after yield recalculation, ensuring contracts whose yield has been recomputed are rebooked consistently.

All public procedures conform to the OKC_API error-handling convention, invoking START_ACTIVITY to create a savepoint, verify API version compatibility, and initialize the message list, then returning standard x_return_status, x_msg_count, and x_msg_data values. No parameter lists are reproduced here beyond those visible in the supplied source excerpt.

Tables Accessed

The documented table references are FA_BOOKS and OKL_MASS_RBK_CRITERIA, accessed through APPS synonyms.

• OKL_MASS_RBK_CRITERIA — Stores the user-supplied selection criteria keyed by request name. BUILD_AND_GET_CONTRACTS reads this table to construct the dynamic SQL that determines which contracts qualify for rebooking.
• FA_BOOKS — The Oracle Assets book definition table, read to resolve accounting book and depreciation parameters relevant to the rebook operation.

The source additionally references OKL_RBK_SELECTED_CONTRACT as the destination work table populated by the selection procedure and subsequently processed by the rebook execution procedures.

Usage Notes

OKL_MASS_REBOOK_PUB is typically invoked from a concurrent program in the Lease Management responsibility that submits the mass rebook request, with the request name linking the run to its criteria in OKL_MASS_RBK_CRITERIA. It may also be called from the Lease Management forms layer or from custom PL/SQL that requires programmatic mass rebooking. Because all entry points are public APIs, callers must supply a valid API version, request message-list initialization as required, and inspect the returned status values. The package is referenced by six other packages within the OKL schema, indicating it participates in a wider dependent processing chain rather than operating in isolation. Custom code should never update the underlying work tables directly; the exposed procedures are the supported integration surface.