Search Results oe_cansrv




Overview
Explore in AI Chat

Overview

APPS.OE_CANSRV is a server-side PL/SQL package in Oracle Order Management (Oracle E-Business Suite 12.1.1 / 12.2.2) that encapsulates the cancellation logic for service-related order lines and their associated children. The package is declared AUTHID CURRENT_USER, meaning its SQL executes with the privileges of the invoking schema rather than the defining owner. Its source header ($Header: OECANSVS.pls 115.2 99/07/16 08:10:40) indicates a long-standing, stable code base that has seen minimal revision since the original 11i release.

The central business problem the package addresses is determining whether an order line is eligible for cancellation, coordinating the removal of dependent service lines, and maintaining the integrity of order interface records and holds during the cancellation transaction. In the ETRM 12.2.2 inventory it is classified as API of type OTHER, with ten documented procedures; it is not referenced by any other packaged API, indicating it is typically called directly rather than as a dependency of a higher-level framework routine.

Key Procedures and Functions

  • CHECK_LINE_INTERFACED — Determines whether the specified line has already been interfaced to downstream systems, returning a result indicator used to block or permit cancellation.
  • CHECK_ORDER_INT_RECS_EXIST — Verifies the presence of order interface records for the line and communicates the associated concurrent process identifier.
  • CHECK_ORDER_INT_NOT_IN_PROG — Confirms that no order interface process is currently executing for the line, with an optional error-message flag; returns the concurrent process identifier and a result code.
  • MAKE_DELETE_INT_RECS — Creates delete records in the order interface so that previously interfaced service lines are correctly backed out, taking customer product, service, and temporary mass-transaction identifiers.
  • CANCEL_SERVICE_CHILDREN — Propagates cancellation to dependent service child lines, carrying cancellation code, comment, full-cancel indicator, status, requested quantity, and concurrent process context.
  • CANCEL_LINE — Performs the core cancellation of an individual order line, receiving requested, ordered, and received quantities plus source and line-type codes and returning a result.
  • CANCEL_SERVICE — Cancels a service line itself, taking quantity context, header identifier, cancellation code and comment, and returning a result.
  • HISTORY — Records or retrieves cancellation history for the affected line.
  • HOLDS — Applies or manages holds in connection with the cancellation.
  • ALL_HOLDS — Processes the complete set of holds relevant to the line, ensuring hold state remains consistent after cancellation.

Tables Accessed

  • CS_ORDERS_INTERFACE_S — Service order interface staging rows inspected and updated to determine interfaced status and to write delete records.
  • MTL_SO_RMA_INTERFACE — RMA interface rows relevant when cancelling return-related service lines.
  • MTL_SYSTEM_ITEMS — Item definition attributes consulted for validation of the service item being cancelled.
  • SO_ORDER_CANCELLATIONS — The primary audit table where cancellation reason codes and comments are stored.
  • SO_ORDER_HOLDS and SO_HOLD_RELEASES / SO_HOLD_RELEASES_S — Hold and hold-release records read and maintained so that cancellation does not leave orphaned holds.
  • DUAL — Used for single-row computations and validation checks.

Usage Notes

OE_CANSRV is ordinarily invoked indirectly: the Order Management cancellation form and related concurrent programs call the higher-level cancellation framework, which in turn relies on routines of this package. Customizations that need to cancel service lines programmatically — for example, mass cancellation of service subscriptions or cleanup of partially interfaced orders — may call CANCEL_SERVICE or CANCEL_LINE directly, but must first satisfy the interface and progress checks through CHECK_LINE_INTERFACED, CHECK_ORDER_INT_RECS_EXIST, and CHECK_ORDER_INT_NOT_IN_PROG. All procedures communicate outcome through OUT result parameters, so callers must inspect the returned result code rather than relying on exceptions. Because the package is AUTHID CURRENT_USER, execution privileges derive from the calling schema, and direct invocation should generally be restricted to APPS or equivalent responsibility-owning users.