Search Results lock_sup_inv_dtls




Overview
Explore in AI Chat

Overview

OKL_SUPP_INVOICE_DTLS_PUB is the public application programming interface for managing supplier invoice detail records within the Oracle Lease and Finance Management (OKL) module of Oracle E-Business Suite. The package exposes a controlled, API-driven entry point into the supplier invoice details data model, allowing external callers — forms, concurrent programs, and custom PL/SQL — to create, maintain, validate, lock, and remove supplier invoice line-level detail records without directly manipulating the underlying base tables. This protects data integrity and ensures that all business rules governing supplier invoice processing are consistently applied regardless of the calling channel.

The package is declared with AUTHID CURRENT_USER and follows the standard ETRM public API architecture. It delegates the substantive business logic to the companion private package OKL_SUPP_INVOICE_DTLS_PVT, while this public layer standardizes the interface, error handling, and messaging conventions. Record and table types (sidv_rec_type and sidv_tbl_type) are subtyped from the private package, enabling both single-record and bulk (table-based) operations. Global constants inherited from OKC_API — such as G_COL_NAME_TOKEN, G_PARENT_TABLE_TOKEN, G_CHILD_TABLE_TOKEN, and G_INVALID_VALUE — support the standard OKC validation and message framework, and a user-hook exception (G_EXCEPTION_HALT_VALIDATION) allows extensions to abort validation processing when required.

Key Procedures and Functions

The documented public interface comprises five primary procedures, each delivered in record-based and/or table-based overloads where applicable:

  • CREATE_SUP_INV_DTLS — Inserts new supplier invoice detail records. Accepts a single detail record or a collection of detail records and returns the created records, typically enriched with system-generated identifiers, through the corresponding output parameter.
  • UPDATE_SUP_INVOICE_DTLS (UPDATE_SUP_INV_DTLS) — Modifies existing supplier invoice detail records. Provides both single-record and bulk overloads, returning the updated records to the caller.
  • DELETE_SUP_INV_DTLS — Removes supplier invoice detail records, applying the module's deletion rules and referential safeguards.
  • LOCK_SUP_INV_DTLS — Obtains a logical or database-level lock on supplier invoice detail records, preventing concurrent modification and ensuring transactional consistency when multiple sessions access the same detail data.
  • VALIDATE_SUP_INV_DTLS — The procedure most commonly associated with the search term "validate_sup_inv_dtls." It performs business-rule validation against a supplier invoice detail record or set of records before they are committed, raising or returning validation messages through the standard OKC messaging framework. Callers typically invoke it prior to create or update to catch invalid values early.

All procedures return the conventional ETRM API status signature (x_return_status, x_msg_count, x_msg_data), and honor p_api_version and p_init_msg_list initialization semantics.

Tables Accessed

Per the documented metadata, the package accesses the APPS synonym PLITBLM. This table is referenced in support of the supplier invoice detail processing logic — typically for message, reference, or interface-line handling associated with invoice detail validation and maintenance. The primary detail persistence is handled through the private package's base-table operations, consistent with the ETRM public/private split.

Usage Notes

OKL_SUPP_INVOICE_DTLS_PUB is normally invoked rather than called directly by end users. Typical callers include the Oracle Lease Management supplier invoice entry forms, concurrent programs that import or process supplier invoice details, and custom extensions that need to programmatically maintain invoice detail data. Existing code should subscribe to the public package rather than the _PVT layer, since the public interface is the supported, upgrade-stable contract. Developers should always inspect x_return_status and retrieve messages via OKC_API after every call, and should initialize the message list appropriately using p_init_msg_list. The package is referenced by six other packages, confirming its role as a shared integration point within the OKL module.