Search Results oke_dts_action_pkg




Overview
Explore in AI Chat

Overview

OKE_DTS_ACTION_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the ETRM taxonomy as an "OTHER" API (rather than a public or private API). It belongs to the Oracle Contracts / Project Contracts family of modules (the OKC and OKE prefixes denote Contract Core and Contract Deliverables entities respectively). Its principal business function is to govern and initiate the lifecycle actions that may be performed against contract headers, contract lines, and deliverables managed within the Deliverables Tracking System (DTS). The package validates whether a given operation is permissible for a current status, resolves the correct operating organization, checks dependency and item validity constraints, and then drives the requested action or set of actions. It is defined with AUTHID CURRENT_USER, meaning that it executes with the privileges of the calling user rather than the definer, an important consideration for security and for any custom code that invokes it. The package's header carries an RCS revision tag (OKEDACTS.pls 120.1) indicating it has been maintained as part of the standard EBS code line.

Key Procedures and Functions

The package exposes six documented members. GET_ORG is a function that returns a numeric organization identifier; it derives the correct organization based on a direction indicator combined with ship-from and ship-to organization identifiers, effectively resolving the trading partner organization appropriate to the transaction context. CHECK_OPERATION_ALLOWED is a Boolean function that determines whether a specific operation code is permitted against a given status code; it encapsulates the status-to-operation transition rules that govern contract deliverables, and is the member most often referenced by callers performing conditional enablement or pre-validation logic. CHECK_DEPENDENCIES is a Boolean function that evaluates whether the prerequisite dependencies for a given deliverable have been satisfied, using the deliverable identifier as the key. CHECK_ITEM_VALID is a Boolean function that confirms that a specified item is valid within a specified inventory organization, preventing actions against items that are not assigned or enabled in that organization. INITIATE_ACTIONS is a procedure that performs the actual action processing; it accepts an action name, an action level (1 for Header, 2 for Line, 3 for Deliverable), and the relevant header, line, and deliverable identifiers, returning status, message data, and message count through OUT NOCOPY parameters. INITIATE_ACTIONS_CP is a concurrent-program wrapper around INITIATE_ACTIONS that exposes the standard ERRBUF and RETCODE parameters required by the concurrent manager, accepting the same action, action level, and identifier arguments.

Tables Accessed

The package reads and writes a defined set of base tables and APPS synonyms. Contract and deliverable data reside in OKC_K_HEADERS_B, OKC_K_LINES_B, OKE_K_HEADERS, and OKE_K_DELIVERABLES_B, while dependency rules are sourced from OKE_DEPENDENCIES and contract assents from OKC_ASSENTS. Organizational and project context is drawn from HR_ALL_ORGANIZATION_UNITS, PA_PROJECTS_ALL, and PA_TASKS. Scheduling reference data is read from MRP_SCHEDULE_DATES, and requisition staging data from PO_REQUISITIONS_INTERFACE_ALL. The DUAL table is used for singleton evaluations. These table references are exposed through APPS synonyms, so the package depends on the standard EBS synonym layer being intact.

Usage Notes

OKE_DTS_ACTION_PKG is referenced by two other packages in the EBS schema, indicating it is an internal service layer consumed by higher-level contract and deliverable processing logic rather than a standalone entry point. INITIATE_ACTIONS_CP is designed for registration as a concurrent program, allowing administrators to launch contract deliverable actions in batch. In form-based flows, the Boolean validation functions (CHECK_OPERATION_ALLOWED, CHECK_DEPENDENCIES, CHECK_ITEM_VALID) are typically called to enable, disable, or warn on user interface actions before the corresponding DML is attempted. Custom extensions should invoke the package with the package owner's grants in mind and should always inspect X_RETURN_STATUS, X_MSG_DATA, and X_MSG_COUNT after calling INITIATE_ACTIONS to correctly propagate error conditions to the end user. Because the package runs as AUTHID CURRENT_USER, callers must ensure their own session privileges include the necessary object access.