Search Results close_sr_children




Overview

APPS.CS_SR_STATUS_PROPAGATION_PKG is a PL/SQL package in the Oracle E-Business Suite Service (CS) module that manages the propagation of service request status changes across related entities. Its central business role is to maintain status consistency between a parent service request and the records that depend on or relate to it, particularly when closures or status transitions occur up or down an association hierarchy. Rather than requiring users or concurrent programs to update each dependent record manually, this package centralizes the logic that drives status transitions through the service request relationship network.

The package is classified in the ETRM metadata as an API of type OTHER and holds the status VALID in the APPS schema. It operates on the Oracle EBS 12.1.1 and 12.2.2 releases and is recorded as a dependency of CS_SERVICEREQUEST_PVT, which indicates that the core service request business logic delegates status propagation work to this package. It is also referenced by CS_WF_EVENT_SUBSCRIPTIONS_PKG and by itself, reflecting its role both in the workflow event subscription layer and in internal recursive processing.

Key Procedures and Functions

The ETRM metadata documents three procedures or functions within this package:

  • VALIDATE_SR_CLOSURE — Validates whether a service request is eligible for closure. This procedure is used to enforce the business rules and conditions that must be satisfied before a service request can be transitioned to a closed status, typically accounting for associated child records or outstanding dependencies.
  • CLOSE_SR_CHILDREN — Handles the closure of child service requests associated with a parent. When a parent service request is closed, this procedure cascades the closure to its descendants in the relationship hierarchy, ensuring that dependent service requests are not left in an inconsistent open state.
  • SR_UPWARD_STATUS_PROPAGATION — Performs upward status propagation, moving status information from child service requests toward their parents. This is the complementary direction to child closure, allowing a parent record to reflect the aggregate or resultant state of the service requests beneath it.

These three routines together implement bidirectional status management: downward cascade for closure and upward propagation for status reflection. The package name itself indicates that status propagation is its primary concern.

Tables Accessed

The documented table references, resolved through APPS synonyms, span the Service, depot repair, enterprise asset management, and resource modules:

  • CS_INCIDENTS_ALL_B and CS_INCIDENT_STATUSES_B — The base service request (incident) table and its status definitions. These are the primary records whose status is read and updated during propagation.
  • AHL_UE_RELATIONSHIPS — Stores the relationship hierarchy between service request entities, enabling the package to determine parent-child links for cascading closures and upward propagation.
  • CSD_REPAIRS and CS_ESTIMATE_DETAILS — Depot repair and estimate records, which represent downstream work whose status must be consistent with the service request.
  • EAM_WO_SERVICE_ASSOCIATION — Associates enterprise asset management work orders with service requests, connecting maintenance activity to service request status.
  • JTF_TASKS_B and JTF_TASK_TYPES_B — Task records and task type definitions that may be linked to the service request lifecycle.
  • JTF_RS_RESOURCE_EXTNS — Resource information, relevant for determining ownership or assignment during status transitions.

The breadth of these references confirms that status propagation must respect dependencies across repair, asset, and task domains, not merely the incidents table.

Usage Notes

This package is not intended for direct invocation by end users. It is invoked internally by CS_SERVICEREQUEST_PVT, the primary service request API, whenever a status change or closure operation is performed through the standard Service Request forms or associated business flows. The dependency on CS_WF_EVENT_SUBSCRIPTIONS_PKG indicates that workflow event subscriptions can also trigger its logic, meaning status propagation may occur in response to workflow-driven events rather than only direct user actions.

Because the routines enforce dependency validation and cascading updates, customizations that bypass CS_SERVICEREQUEST_PVT and update CS_INCIDENTS_ALL_B directly risk leaving child service requests, repairs, work orders, or tasks in an inconsistent state. Customers extending Service functionality should route status changes through the standard API so that VALIDATE_SR_CLOSURE, CLOSE_SR_CHILDREN, and SR_UPWARD_STATUS_PROPAGATION execute as designed.

The package is schema-owned by APPS and grants access through standard EBS synonym and grant conventions; any custom code referencing it should do so as APPS.CS_SR_STATUS_PROPAGATION_PKG. Its limited documented dependency set (FND_API and STANDARD) and its two known referencing packages define the supported integration surface.