Search Results delete_contract_details

Overview

OKS_OMINT_PUB is a public PL/SQL package in the APPS schema that supports Oracle Service (formerly Service Contracts) integration with Oracle Order Management. The package name reflects its role as a "service order management integration" API: it exposes serviceability and availability checks, duration and quantity derivation, service date retrieval, contract detail maintenance, and the interface of service order lines between the order management and service contracts domains.

In Oracle EBS 12.1.1 and 12.2.2, OKS_OMINT_PUB is classified as a PUB (public) API package, meaning it is intended for external invocation by other application modules, extensions, and custom code. ETRM documents the package as VALID in the APPS schema and defines its dependency footprint, establishing it as a stable integration point within the service-to-order flow. Its principal upstream dependency is OKC_API, the core contracts API, from which it inherits contract structure handling for the OKC_K_ITEMS and OKC_K_LINES_B entities.

Key Procedures and Functions

ETRM documents eleven procedures and functions on OKS_OMINT_PUB:

• GET_DURATION — Returns the duration associated with a service, used to determine service term length for order lines.
• IS_SERVICE_AVAILABLE — Boolean-style availability check that indicates whether a given service can be offered for the supplied context.
• AVAILABLE_SERVICES — Retrieves the set of services available for a customer, product instance, or system.
• OKS_AVAILABLE_SERVICES — Companion routine providing the service-specific available-services result set.
• DELETE_CONTRACT_DETAILS — Removes contract detail records associated with service order processing, used during clean-up or reversal.
• GET_SVC_SDATE — Returns the service start date used to align order line dates with contract coverage.
• INTERFACE_SERVICE_ORDER_LINES — The primary integration routine, moving service order lines between Order Management and the service contracts schema.
• GET_QUANTITY — Derives the service quantity applicable to an order line.
• GET_TARGET_DURATION — Returns the target duration for a service, distinct from the actual duration returned by GET_DURATION.

These routines collectively cover serviceability, pricing input, and contract line creation for service-enabled order lines. Parameter lists are not documented in ETRM and are therefore not stated here.

Tables Accessed

The package operates across the service, customer, and order data model via APPS synonyms:

• Installed base and systems: CSI_ITEM_INSTANCES, CS_SYSTEMS_ALL_B, CS_CUSTOMER_PRODUCTS_ALL, CS_CUSTOMER_PRODUCT_STATUSES — used to identify the customer's installed products and systems for serviceability and availability checks.
• Contract structures: OKC_K_ITEMS, OKC_K_LINES_B — contract item and line storage populated by interface_service_order_lines and cleaned by delete_contract_details.
• Service order artifacts: OKS_K_ORDER_DETAILS, OKS_K_ORDER_CONTACTS, OKS_REPROCESSING — service order detail, contact, and reprocessing records.
• Order management: OE_ORDER_LINES_ALL, OE_SYSTEM_PARAMETERS_ALL — order line source/target records and profile defaults.
• Reference and master data: MTL_SYSTEM_ITEMS_TL, MTL_UNITS_OF_MEASURE_TL, FND_LOOKUP_VALUES, HZ_CUST_ACCOUNTS — item descriptions, units of measure, lookup values, and customer accounts.

Usage Notes

OKS_OMINT_PUB is invoked behind the scenes by Order Management and Service Contracts flows rather than directly by end users. ETRM records that it is referenced by twelve other packages, including ASO_PRICING_CORE_PVT, ASO_SERVICE_CONTRACTS_INT, ASO_SERVICE_CONTRACTS_INT_W, IBE_CATALOG_PVT, IBE_PRICE_PVT, OE_LINE_FULLFILL, OE_ORDER_PRICE_PVT, OKS_QA_DATA_INTEGRITY, QP_PREQ_GRP, and QP_RESOLVE_INCOMPATABILITY_PVT. This citation pattern indicates that serviceability and duration data supplied by OKS_OMINT_PUB feed pricing, catalog, order fulfillment, and quality/integrity checks.

Typical triggers include order entry with service items, service contract integration concurrent programs, iStore catalog and pricing resolution, and the OKS data integrity checker. Custom code should call the package only through its published entry points and should not depend on internal package body logic, as those structures are not warranted. Because it is a PUB API, callers must observe standard EBS API conventions—explicit commit handling, MOAC/ORG_ID context where applicable, and FND message-based error handling—rather than assuming autonomous transaction behavior.