Search Results csd_repairs_pub




Overview
Explore in AI Chat

Overview

CSD_REPAIRS_PUB is the public application programming interface for repair order processing within the Oracle E-Business Suite Depot Repair module. Owned by the APPS schema and classified as a PUB (public) API package body, it exposes the supported entry points through which external callers — Oracle Forms, concurrent programs, workflow activities, and custom extensions — create and maintain repair orders without directly manipulating the underlying base tables. The package body acts as a thin orchestration layer: it validates inputs, enforces the standard EBS API programming conventions, and delegates the substantive business logic to the private implementation package CSD_REPAIRS_PVT.

Consistent with Oracle's public/private API pattern, CSD_REPAIRS_PUB is the only repair-order package that customers and integrators should invoke directly. It preserves upgrade safety by insulating callers from internal schema and logic changes, and it participates in the standard FND_API error-handling model, returning a success flag and a message list rather than raising unhandled exceptions.

Key Procedures and Functions

The documented interface comprises four procedures:

  • CREATE_REPAIR_ORDER — Creates a new repair order header and its associated repair lines. This is the primary entry point for bringing a repair transaction into Depot Repair, whether originating from an order capture flow, a service request, or an external integration.
  • UPDATE_REPAIR_ORDER — Modifies an existing repair order, including header attributes and line-level details, while applying the module's validation and status rules.
  • UPDATE_REPAIR_TYPE — Changes the repair type assigned to a repair order or line. Repair type drives the applicable routing, costing, and processing rules, so this procedure carries meaningful downstream consequences.
  • UPDATE_RO_STATUS — Transitions a repair order through its lifecycle statuses. This procedure is central to depot workflows, where status governs whether further processing, shipping, or billing may proceed.

All four follow the FND_API calling convention, accepting a standard API parameter list and returning x_return_status and x_msg_count/x_msg_data. Parameter lists are not reproduced here; refer to the ETRM package specification for exact signatures.

Tables Accessed

The ETRM metadata for this object does not enumerate base tables. All table access is performed indirectly through the private package CSD_REPAIRS_PVT, which is the layer that performs the actual DML against the CSD repair order schema objects. This indirection is intentional: the public package contains no direct SQL against the repair tables, and its documented dependencies list only other PL/SQL units — CSD_REPAIRS_PVT, CSD_PROCESS_UTIL, CSD_LOGISTICS_PVT, CSD_GEN_UTILITY_PVT, CSD_RO_BULLETINS_PVT, FND_API, FND_LOG, FND_MSG_PUB, FND_PROFILE, and JTF_PLSQL_API. Because CSD_REPAIRS_PUB is not referenced by any database object, its own dependency surface is limited to the units it calls.

Usage Notes

CSD_REPAIRS_PUB is normally invoked from the Depot Repair Oracle Forms user interface, from concurrent programs performing batch repair order maintenance, and from workflow or business event subscribers. Custom code should call this package rather than executing DML against the repair order tables, because the public API enforces required validations, handles message stack management, and records debug information through FND_LOG when the appropriate profile options are enabled.

The package is referenced by nineteen other database objects, confirming its role as an established integration point. When invoking these procedures, callers must check x_return_status and retrieve messages via FND_MSG_PUB before committing. For release-specific behavior between 12.1.1 and 12.2.2, verify the package specification shipped with the installed patch level, as signature and validation changes may accompany online patching updates.