Search Results requirement_operations
Overview
APPS.MRP_RESCHEDULE_CMRO_WO_PS is a packaged PL/SQL body used by Oracle E-Business Suite planning and maintenance execution flows to release and reschedule work orders originating from a planner workbench or supply scheduling context. The package header version recorded here (120.19, dated 2012/03/08) identifies it as a shipped, non-customized Oracle module. Its primary business role is to accept an aggregated planning group identifier, read staged work order records from the WIP and planning interface tables, and either release those work orders or reschedule them by writing supply schedule rows into AHL_REQ_SUPPLY_SCHEDULE.
The name itself encodes the function: MRP (planning), RESCHEDULE, CMRO (Complex/Contract Maintenance Repair Order constructs used in Enterprise Asset Management), WO (work order), and PS (planner / supply schedule). The package is therefore most closely associated with the interface between Oracle Advanced Supply Chain Planning (ASCP) or MRP and the Oracle Enterprise Asset Management (EAM) work order execution model. It supports the release of maintenance-related work orders that were planned in a planning server instance and need to be propagated to the execution instance through a database link. The presence of G_group_id, G_sr_instance_id, and g_dblink global variables confirms that the package operates on a batch of records tied to a planning group and, optionally, a remote instance.
Key Procedures and Functions
The package exposes twelve documented procedures and functions, organized as a main entry point plus supporting helpers:
- RESCHEDULE_CMRO_WO — Top-level entry point that reschedules maintenance work orders. It orchestrates the retrieval, detail population, and subsequent release logic for a given planning group.
- PROCESS_SINGLE_WO — Processes one individual work order through the reschedule/release pipeline.
- RELEASE_CMRO_WO — Accepts a group_id and populates AHL_REQ_SUPPLY_SCHEDULE from staged WIP interface records; the primary release routine.
- PROCESS_SINGLE_WO_EAM — EAM-specific single work order processing, handling maintenance object source semantics.
- GET_WO_DETAIL — Retrieves work order header level detail.
- GET_OP_DETAIL — Retrieves work order operation detail.
- GET_RES_DETAIL — Retrieves resource detail for operations.
- GET_MAT_DETAIL — Retrieves material requirement detail for work orders.
- GET_SUB_MAT_DETAIL — Retrieves subordinate or substitute material detail.
- GET_RES_INST_DETAIL — Retrieves resource instance detail.
- GET_RES_USAGE_DETAIL — Retrieves resource usage detail.
- POPULATE_MISSING_DETAILS — Fills in detail records that were not supplied in the original staged rows.
Tables Accessed
- AHL_REQ_SUPPLY_SCHEDULE — The primary target table; the package writes requested supply schedule rows that represent released or rescheduled maintenance work orders.
- WIP_OPERATIONS — Read to obtain operation-level routing information for the work orders being rescheduled.
- PLITBLM — An Oracle Applications internal PL/SQL table/collection utility used for array handling within the package.
- V$PARAMETER2 — Read to determine database instance parameters, typically to support conditional behavior across instances or links.
The source excerpt additionally references MSC_WIP_JOB_SCHEDULE_INTERFACE and MSC_WIP_JOB_DTLS_INTERFACE, which are the planning staging tables from which the work order and detail rows are sourced. These are read via a dynamically constructed SQL statement so the package can optionally route reads through a database link.
Usage Notes
The package is invoked as a batch/backend routine rather than from a direct form interaction. Typical invocation paths include concurrent program wrappers that supply P_GROUP_ID, P_SR_INSTANCE_ID, and P_DBLINK, and internal calls from MRP/MSC planning processes that push planned maintenance work orders into EAM execution. Its ERRBUF and RETCODE NOCOPY output parameters conform to the standard concurrent program calling convention.
Because it reads from interface tables and writes into AHL_REQ_SUPPLY_SCHEDULE, it should be invoked after the planning interface has been populated for the relevant group_id and, where applicable, before downstream EAM work order creation. Debugging is supported through the log_output helper, which writes to FND_FILE.OUTPUT so messages appear in the concurrent request log. The package is documented as not being referenced by other packages, indicating it functions as an entry point rather than a shared utility.