Search Results create_order_from_k
Overview
OKS_KTO_INT_PUB is a public PL/SQL API package in the Oracle E-Business Suite Service Contracts (OKS) module, defined under the APPS schema with AUTHID CURRENT_USER privileges. Its name reflects its purpose: the interface that bridges the "K" side of the data model (contracts, stored in the OKC schema objects) and the "TO" side (orders, managed by Order Management). The package header cites the K->O conversion, and the source header comment ($Header: OKSPORDS.pls) confirms that the package was created to support Service Contracts-to-Order flows.
The business function is straightforward: given an existing service contract, the API orchestrates the creation of a corresponding sales order in Order Management. The package is classified as a PUB (public) API, meaning Oracle supports its direct invocation from customer extensions, concurrent programs, and other application code. This makes it a supported integration point for organizations that need to automate order generation from contract data, for example when a service contract must be fulfilled through standard order-management fulfillment, pricing, and shipping processes.
Key Procedures and Functions
The package exposes two overloaded variants of a single documented procedure, CREATE_ORDER_FROM_K:
- create_order_from_k (concurrent-program variant) — This version uses the standard concurrent-program parameter signature (ERRBUF, RETCODE) and is intended to be invoked from a concurrent program. It accepts the contract for which the order should be created and a set of optional defaults for the default date, customer, group, organization, and contract/contract-line ID ranges. This is the entry point that schedules or launches the order creation in batch mode.
- create_order_from_k (PL/SQL API variant) — This version follows the standard EBS API convention (p_api_version, p_init_msg_list, p_commit, x_return_status, x_msg_count, x_msg_data) and is intended for direct programmatic invocation from custom code or other PL/SQL packages. It accepts the same core contract and default parameters as the concurrent-program variant, allowing callers to control commit behavior and inspect return status and message details after execution.
Per the source comments, the first variant is planned to be called by a concurrent program and internally calls the second variant. The second variant, in turn, calls ASO_ORDER_PUB.CREATE_ORDER to actually create the order. The primary output is the identifier of the created order, returned through the x_order_id out parameter. The optional P_contract_hdr_id_lo/hi and P_contract_line_id_lo/hi parameters (added under Bug 4915691) allow callers to restrict processing to a range of contracts or contract lines, which is useful for batch processing scenarios.
Tables Accessed
The documented table reference is OKC_K_HEADERS_B, the base table of contract headers in the Service Contracts data model. The p_contract_id parameter is declared with the okc_k_headers_b.ID%TYPE datatype, tying the API directly to the contract header key. The package reads the contract header (and, through the flow, its lines) to derive the information required to build the sales order. The actual order insertion is delegated to ASO_ORDER_PUB.CREATE_ORDER, which writes to the Order Management tables (OE_ORDER_HEADERS_ALL and related tables). The package itself does not directly manipulate the OM tables; it acts as the orchestration layer that prepares order data from contract data and passes it to the supported Order Management API.
Usage Notes
OKS_KTO_INT_PUB is typically invoked in two ways. First, through a concurrent program registered in Oracle EBS, where the concurrent-program variant of CREATE_ORDER_FROM_K receives the standard ERRBUF/RETCODE parameters and the contract selection parameters from the concurrent program definition. Second, from custom PL/SQL code, where developers call the API-style variant with p_api_version, p_init_msg_list, and p_commit to control transaction boundaries and then inspect x_return_status, x_msg_count, and x_msg_data for error handling. This dual interface pattern is standard in EBS and makes the package suitable both for scheduled batch conversion and for event-driven integration from forms, workflows, or external systems.
The metadata indicates that the package is referenced by one other package, confirming that it participates in a larger dependency chain within the Service Contracts and Order Management integration. Because the metadata excerpt is limited, the exact columns populated and the precise mapping between contract attributes and order attributes are not enumerated here; developers should review the full package body (OKSPORDS.pls) and the ASO_ORDER_PUB API documentation before implementing customizations.
-
PACKAGE: APPS.OKS_KTO_INT_PUB
12.2.2
-
PACKAGE: APPS.OKS_OC_INT_KTO_PVT
12.1.1
-
PACKAGE BODY: APPS.OKC_OC_INT_KTO_PVT
12.2.2
-
PACKAGE BODY: APPS.OKS_KTO_INT_PUB
12.1.1
-
PACKAGE BODY: APPS.OKS_KTO_INT_PUB
12.2.2
-
PACKAGE: APPS.OKS_KTO_INT_PUB
12.1.1
-
PACKAGE BODY: APPS.OKC_OC_INT_KTO_PVT
12.1.1
-
PACKAGE: APPS.OKS_OC_INT_KTO_PVT
12.2.2
-
PACKAGE: APPS.OKC_OC_INT_KTO_PVT
12.1.1
-
PACKAGE: APPS.OKC_OC_INT_KTO_PVT
12.2.2
-
PACKAGE: APPS.OKC_OC_INT_PUB
12.2.2
-
PACKAGE: APPS.OKC_OC_INT_PUB
12.1.1
-
PACKAGE BODY: APPS.OKC_OC_INT_PUB
12.2.2
-
PACKAGE BODY: APPS.OKC_OC_INT_PUB
12.1.1
-
PACKAGE BODY: APPS.OKS_OC_INT_KTO_PVT
12.2.2
-
PACKAGE BODY: APPS.OKS_OC_INT_KTO_PVT
12.1.1
-
APPS.OKS_KTO_INT_PUB dependencies on OKS_KTO_INT_PUB
12.1.1
-
APPS.OKS_KTO_INT_PUB dependencies on OKC_API
12.1.1
-
APPS.OKS_KTO_INT_PUB dependencies on OKC_API
12.2.2
-
APPS.OKS_KTO_INT_PUB dependencies on OKS_KTO_INT_PUB
12.2.2
-
APPS.OKS_OC_INT_KTO_PVT dependencies on OKX_ORDER_HEADERS_V
12.1.1
-
APPS.OKS_OC_INT_KTO_PVT dependencies on OKC_API
12.1.1
-
APPS.OKS_OC_INT_KTO_PVT dependencies on OKX_ORDER_HEADERS_V
12.2.2
-
APPS.OKS_OC_INT_KTO_PVT dependencies on OKC_API
12.2.2
-
APPS.OKS_KTO_INT_PUB dependencies on OKC_K_HEADERS_B
12.1.1
-
APPS.OKS_KTO_INT_PUB dependencies on OKC_API
12.1.1
-
APPS.OKC_OC_INT_KTO_PVT dependencies on OKX_ORDER_HEADERS_V
12.1.1
-
APPS.OKS_KTO_INT_PUB dependencies on OKC_K_HEADERS_B
12.2.2
-
APPS.OKS_OC_INT_KTO_PVT dependencies on OKS_OC_INT_KTO_PVT
12.1.1
-
APPS.OKS_KTO_INT_PUB dependencies on OKC_K_HEADERS_B
12.1.1
-
APPS.OKS_OC_INT_KTO_PVT dependencies on OKS_OC_INT_KTO_PVT
12.2.2
-
APPS.OKS_KTO_INT_PUB dependencies on OKC_K_HEADERS_B
12.2.2
-
APPS.OKC_OC_INT_KTO_PVT dependencies on OKX_ORDER_HEADERS_V
12.2.2
-
APPS.OKS_KTO_INT_PUB dependencies on OKC_API
12.2.2
-
APPS.OKC_OC_INT_PUB dependencies on OKC_K_HEADERS_B
12.1.1
-
APPS.OKC_OC_INT_PUB dependencies on OKC_K_HEADERS_B
12.2.2
-
APPS.OKC_OC_INT_PUB dependencies on OKC_K_HEADERS_B
12.1.1
-
APPS.OKC_OC_INT_KTO_PVT dependencies on OKC_API
12.2.2
-
APPS.OKC_OC_INT_PUB dependencies on OKC_K_HEADERS_B
12.2.2
-
APPS.OKC_OC_INT_KTO_PVT dependencies on OKC_API
12.1.1
-
APPS.OKC_OC_INT_PUB dependencies on OKC_API
12.1.1
-
APPS.OKC_OC_INT_PUB dependencies on OKC_API
12.2.2
-
APPS.OKS_OC_INT_KTO_PVT dependencies on OKC_API
12.1.1
-
APPS.OKS_OC_INT_KTO_PVT dependencies on OKC_API
12.2.2
-
APPS.OKC_OC_INT_PUB dependencies on OKC_API
12.1.1
-
APPS.OKC_OC_INT_PUB dependencies on OKC_API
12.2.2