Search Results update_group_approval_status

Overview

CSD_REPAIRS_GRP is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified as a Group (GRP) API within the Depot Repair module of Oracle Enterprise Asset Management and Service. In EBS 12.1.1 and 12.2.2, the CSD schema family supports the Depot Repair business flow—receiving customer or internal items, creating repair orders, estimating costs, approving and tracking repair work, and returning the repaired goods. CSD_REPAIRS_GRP serves as the central repository-level API that encapsulates the logic for creating, updating, and advancing the lifecycle state of repair orders recorded in the CSD_REPAIRS table. Its GRP classification indicates that it is an internal processing package intended to be called by other program units rather than being bound directly to a form or user interface. The package status is documented as VALID, confirming that it compiles cleanly and is available at runtime. It depends on the FND_API package for standard Oracle Application Object Library error-handling and message stack utilities.

Key Procedures and Functions

The ETRM metadata documents six public program units within the package. Their purposes are as follows:

• CREATE_REPAIR_ORDER — Creates a new repair order record, establishing the header-level repair context within the Depot Repair process.
• UPDATE_REPAIR_ORDER — Modifies attributes of an existing repair order, allowing changes to be applied to a repair in progress.
• UPDATE_APPROVAL_STATUS — Sets or advances the approval status of an individual repair order, used when repair work must be authorized before proceeding.
• UPDATE_STATUS — Updates the general lifecycle status of a single repair order (for example, moving it through stages such as received, in repair, or completed).
• UPDATE_GROUP_APPROVAL_STATUS — Applies an approval status change across a group or set of repair orders in a single operation, supporting bulk approval scenarios.
• UPDATE_GROUP_REJECT_STATUS — Applies a rejection status across a group of repair orders, enabling bulk rejection processing parallel to the group approval routine.

The presence of paired group update procedures alongside their single-record counterparts reflects a deliberate design that allows both interactive and batch (mass) processing of repair orders.

Tables Accessed

The package manipulates data through APPS synonyms that resolve to the following base tables:

• CSD_REPAIRS — The primary Depot Repair order table. It stores repair order headers and is the target of the CREATE_REPAIR_ORDER, UPDATE_REPAIR_ORDER, UPDATE_STATUS, UPDATE_APPROVAL_STATUS, UPDATE_GROUP_APPROVAL_STATUS, and UPDATE_GROUP_REJECT_STATUS operations. Essentially all status and lifecycle changes recorded by the package are persisted here.
• CSD_REPAIR_ESTIMATE — The repair estimate table, which holds cost and estimate lines associated with a repair order. The package consults this table where estimate data is required to validate or support repair order processing.

Usage Notes

CSD_REPAIRS_GRP is an internal Group API and is not designed for direct end-user invocation. It is referenced by two other program units within the CSD schema: CSD_REPAIR_ESTIMATE_PVT and CSD_ISUP_DEPOT_WF_PVT, the latter being the Depot Repair workflow processing package. This dependency pattern confirms that repair order creation, status transitions, and approval handling are driven by the Depot Repair workflow and the estimate processing logic rather than by a form calling the package directly. In practice, the package is invoked when repair orders are established through the Depot Repair flow, when estimates are finalized, and when workflow events trigger approval or rejection of repair work—including the group approval and group rejection paths used to process multiple orders at once. Development and extension efforts should treat CSD_REPAIRS_GRP as a lower-level service API: callers should route through the higher-level public APIs (such as CSD_REPAIR_ESTIMATE_PVT) and the seeded workflow rather than calling these procedures directly, to ensure that status validation, approval rules, and FND_API error handling are correctly applied. Any custom code that does call these procedures directly must observe the same validation and error-handling conventions and should be regression-tested against both 12.1.1 and 12.2.2, since the package is shared across both releases.