Search Results okl_option_rules_pvt




Overview
Explore in AI Chat

Overview

OKL_OPTION_RULES_PVT is a private PL/SQL package body in the APPS schema that encapsulates the business logic governing option rules within the Oracle Lease Management (OKL) module of Oracle E-Business Suite. Option rules define the contractual conditions and eligibility criteria attached to lease options, including purchase options, renewal options, and termination options. This package serves as the private implementation layer of the option rules API, providing the core create, update, validate, lock, and delete operations that are exposed to callers through the public OKL_OPTION_RULES_PUB or equivalent wrapper interface. As a PVT package, it is not intended for direct invocation by external applications; instead, it is called by other PL/SQL constructs within the OKL product family to maintain the integrity of option rule data throughout the lease lifecycle.

Key Procedures and Functions

The package exposes a documented set of procedures and functions organized around two functional groups: option rules and option validation rules. Each group follows a consistent lifecycle pattern that includes creation, modification, validation, locking, and deletion.

  • CREATE_OPTION_RULES — Inserts a new option rule definition into the underlying tables, establishing the association between a lease option and its governing rules.
  • UPDATE_OPTION_RULES — Modifies the attributes of an existing option rule record, applying changes to the rule configuration.
  • VALIDATE_OPTION_RULES — Performs logical and referential validation on option rule data prior to persistence, ensuring that required attributes and business constraints are satisfied.
  • LOCK_OPTION_RULES — Obtains a lock on the option rule record, typically to serialize concurrent modification attempts within a transaction.
  • DELETE_OPTION_RULES — Removes an option rule record, subject to validation and referential integrity checks.
  • CREATE_OPTION_VAL_RULES — Inserts an option validation rule, which defines the criteria used to evaluate whether an option is valid under specified conditions.
  • LOCK_OPTION_VAL_RULES — Locks an option validation rule record for controlled concurrent access.
  • UPDATE_OPTION_VAL_RULES — Modifies the attributes of an existing option validation rule.
  • DELETE_OPTION_VAL_RULES — Removes an option validation rule record.
  • VALIDATE_OPTION_VAL_RULES — Validates option validation rule data before it is written to the database.

The documented metadata lists 23 public procedures and functions in total, of which the ten above represent the principal documented entry points. The remainder support internal processing such as defaulting, error handling, and inter-package coordination.

Tables Accessed

The package operates primarily against the option rules view and its base tables. The documented reference to OKL_OPV_RULES_V indicates that option validation rule data is read through this view, which likely joins the option validation definition tables with related option master data. The package also references PLITBLM, the PL/SQL integer table type synonym used within the EBS environment for passing collections between PL/SQL layers; this is a structural dependency rather than a business data table. Access to base option rules and option validation rule tables occurs through the DML statements issued by the create, update, and delete procedures.

Usage Notes

OKL_OPTION_RULES_PVT is invoked by the OKL_ORL_PVT and OKL_OVD_PVT packages, both of which are listed as dependencies and appear to provide higher-level option rule list and option validation defaulting services. Callers supply data through the EBS standard API pattern, relying on FND_API for message handling and OKC_API for contract-related utilities. Because the package body is classified as PVT and is not referenced by any other database object, it should not be called directly from custom forms or concurrent programs; instead, integrators should invoke the corresponding public API. The package is transaction-aware and is typically executed within an existing transaction controlled by the calling form or concurrent manager. Error conditions are surfaced through the standard FND_API exception mechanism rather than through return codes, so callers must be prepared to handle exceptions raised during validation and DML operations. In ETRM 12.1.1 and 12.2.2 the object remains VALID, confirming compatibility across both release levels.