Search Results lock_contract_header

Overview

OKL_CONTRACT_PVT is a private (PVT) PL/SQL package in the Oracle E-Business Suite Applications (APPS) schema, belonging to the Oracle Lease and Finance Management (OKL) product within the ETRM (Enterprise Contract and Transaction Management) family. It is declared with AUTHID CURRENT_USER and carries the internal identifier OKL_CONTRACT_PVT, with the header comment placing its origin in the 11.x/12.x development stream. The package encapsulates the core business logic for creating, maintaining, validating, deleting, and locking the primary contract structures used by lease and finance agreements: the contract header, contract lines, and governance records. These entities map onto the shared Oracle Contracts (OKC) data model, which OKL reuses to store contract headers, lines, rule groups, rules, statuses, and party roles. As a PVT package, it is not intended as a public API; it provides the internal implementation consumed by other OKL packages and public wrappers, shielding calling code from the underlying OKC table structure and the sequencing, validation, and lock management that must occur consistently on every contract operation.

Key Procedures and Functions

The package exposes a symmetrical set of procedures for each of the three major entity families. Parameter lists are not reproduced here; the documented procedures are as follows.

• Contract Header operations: CREATE_CONTRACT_HEADER, UPDATE_CONTRACT_HEADER, DELETE_CONTRACT_HEADER, LOCK_CONTRACT_HEADER, and VALIDATE_CONTRACT_HEADER manage the lifecycle of the contract header, including the migration-based creation and update overloads visible in the source excerpt, which accept header record and table types (chrv_rec_type, chrv_tbl_type, khrv_rec_type, khrv_tbl_type) and support single-record and bulk-array processing with restricted-update control.
• Contract Line operations: CREATE_CONTRACT_LINE, UPDATE_CONTRACT_LINE, DELETE_CONTRACT_LINE, LOCK_CONTRACT_LINE, and VALIDATE_CONTRACT_LINE provide the same lifecycle coverage for contract lines and their translated attributes.
• Governance operations: CREATE_GOVERNANCE, UPDATE_GOVERNANCE, DELETE_GOVERNANCE, LOCK_GOVERNANCE, and VALIDATE_GOVERNANCE maintain governance records attached to contracts.
• Whole-contract and utility routines: DELETE_CONTRACT removes an entire contract; GET_CONTRACT_HEADER_INFO retrieves header details; INCREMENT_MINOR_VERSION advances the contract's minor version, supporting versioning of contract changes.

Tables Accessed

The package operates against shared OKC objects through APPS synonyms. It reads and writes OKC_K_HEADERS_B and its history table OKC_K_HEADERS_BH for header data; OKC_K_LINES_B and OKC_K_LINES_TL for line definitions and translations; OKC_K_ITEMS, OKC_LINE_STYLES_B, OKC_RULES_B, and OKC_RULE_GROUPS_B for line-level configuration and rule assignment; OKC_STATUSES_B and OKC_STATUSES_TL for contract and line status values; OKC_K_PARTY_ROLES_B for party roles attached to contracts; and OKC_GOVERNANCES for governance records. GL_CURRENCIES supplies currency validation, FND_PROFILE_OPTION_VALUES provides profile option settings, and OKL_FAN_SEQ is the OKL sequence used to generate identifiers. These tables are accessed to persist contract structure, enforce referential and status consistency, and supply lookup data during validation.

Usage Notes

OKL_CONTRACT_PVT is an internal implementation package and is referenced by 14 other packages; direct invocation from custom code is therefore discouraged in favor of the corresponding public OKL APIs. It is typically called from the OKL Lease Management forms and concurrent programs during contract entry, amendment, migration, and termination processing, and its LOCK_CONTRACT_HEADER, LOCK_CONTRACT_LINE, and LOCK_GOVERNANCE routines are used to obtain and record concurrency locks prior to updates. Custom extensions that must preserve validation, status, and versioning behavior should route through the public API layer, which in turn delegates to this package. In EBS 12.1.1 and 12.2.2, the package remains schema-qualified under APPS and follows standard API conventions, including the p_api_version, p_init_msg_list, x_return_status, x_msg_count, and x_msg_data parameter pattern.