Search Results oks_order_details_pub




Overview
Explore in AI Chat

Overview

OKS_ORDER_DETAILS_PUB is a public PL/SQL API package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Oracle Knowledge System (OKS) module — more commonly known as the Service Contracts or Enterprise Contracts (ETRM) application. The package exposes the order detail maintenance layer that supports quote and order capture, order line detail persistence, and the association of service contract components with order information passed between Oracle Order Management and the service contracts schema.

In EBS terminology, the PUB suffix indicates that this package is a documented public interface, intended for external invocation by forms, concurrent programs, or custom code. The business-layer logic it depends upon resides in OKS_ORDER_DETAILS_PVT, the private package that performs the actual validation and DML. OKS_ORDER_DETAILS_PUB therefore acts as the thin, supported entry point that shields callers from internal implementation details such as direct table access and locking strategies.

Key Procedures and Functions

The ETRM metadata documents ten procedures and functions in this package. The named procedures include:

  • INSERT_ORDER_DETAIL — creates a new order detail record for the specified contract or order line, applying the standard defaulting and validation rules before the row is persisted.
  • LOCK_ORDER_DETAIL — acquires a lock on the order detail row, ensuring concurrency control when simultaneous updates might otherwise conflict. It is typically invoked before update or delete operations.
  • UPDATE_ORDER_DETAIL — modifies the attributes of an existing order detail record, validating the changed values against the configured business rules and re-deriving dependent fields as required.
  • DELETE_ORDER_DETAIL — removes an order detail record (or logically terminates it, depending on the configuration) together with any dependent child rows maintained in OKS.
  • VALIDATE_ORDER_DETAIL — evaluates the order detail data against the validation rules and returns the appropriate success or error status without performing DML. It is frequently called ahead of insert or update so that callers can surface validation errors to the user.

The remaining documented procedures follow the same create-read-update-delete pattern and expose additional query and lock helpers to callers. All business logic is delegated to OKS_ORDER_DETAILS_PVT; the public package is designed so that callers should not modify order detail tables directly.

Tables Accessed

The documented dependency information lists PLITBLM as the base table referenced through APPS synonyms. This table underpins the order detail storage used by Order Capture and Service Contracts integration. All access is routed through the private package, meaning that direct DML against the underlying tables is not supported and may bypass essential validation logic applied by OKS_ORDER_DETAILS_PVT.

Usage Notes

Because OKS_ORDER_DETAILS_PUB is classified as a public API, it is the correct and supported integration point for customizations and extensions within EBS. It is referenced by the following packages: OKS_COVERAGES_PVT, OKS_INTEGRATION_UTIL_PUB, and OKS_OMINT_PUB, confirming its role as a building block within the service contract ordering and Order Management integration flows.

Typical invocation patterns are:

  • Oracle Forms — during order capture and contract authoring, when a user commits changes to order detail lines.
  • Order Management integration — OkS_omint_pub and related integration utilities call the API to keep order detail data synchronized between OM and OKS.
  • Concurrent programs and custom PL/SQL — batch loads and custom programs should call the PUB procedures rather than issuing INSERTs, UPDATEs, or DELETEs against PLITBLM directly.

Callers should invoke VALIDATE_ORDER_DETAIL before INSERT or UPDATE, use LOCK_ORDER_DETAIL before modifying an existing row, and handle any errors returned by the API rather than relying on database exception messages. No parameter lists are documented in the ETRM metadata excerpt, so developers should reference the package specification in the EBS schema for exact argument definitions prior to implementation.