Search Results calc_res_avail

Overview

MRP_RHX_RESOURCE_AVAILABILITY is an Oracle Applications (APPS) PL/SQL package that belongs to the Oracle Master Scheduling/MRP and Oracle Capacity product family. Its purpose is to compute and persist the available capacity of manufacturing resources and departments within an organization over a defined planning horizon. In the context of Oracle E-Business Suite release 12.1.1 and 12.2.2, the package underpins the capacity planning and resource availability calculations consumed by the Oracle Capacity and material requirements planning engines.

The package translates the raw calendar, shift, department, and resource definitions maintained in Oracle Bills of Material into a consolidated availability picture stored in the MRP net resource availability table, which downstream planning processes then query. Because the calculation must respect simulation sets, the package supports "what-if" planning scenarios alongside the live production schedule. The header comment identifies the source file as MRPXNRAS.pls and the package is owned by APPS, classified under the generic OTHER API category, meaning it is a documented but internal-facing program rather than a fully published open interface.

Key Procedures and Functions

The package exposes two documented procedures:

• CALC_RES_AVAIL — Calculates the available capacity for a specific combination of organization, department, and resource. It takes the organization, department, resource, simulation set, a 24-hour flag, an optional start date (defaulting to SYSDATE), and a cutoff date. This procedure performs the granular availability computation for a single resource context, factoring in shift patterns, calendar working days, and any resource change records in effect during the window.
• POPULATE_AVAIL_RESOURCES — The procedure associated with the user's search term "populate_avail_resources." It drives the population of resource availability records across an organization for a given simulation set. Its parameters are the simulation set, organization identifier, an optional start date (default SYSDATE), and an optional cutoff date defaulting to NULL. This is the higher-level driver that iterates over the applicable resources and persists results into the net resource availability table.

Tables Accessed

The package reads from and writes to a defined set of tables, accessed through APPS synonyms:

• BOM_CALENDAR_DATES — working and non-working days used to determine valid production dates.
• BOM_DEPARTMENTS — department definitions that scope the resource availability calculation.
• BOM_DEPARTMENT_RESOURCES — the association of resources to their owning departments.
• BOM_RESOURCE_CHANGES — effective-dated changes to resource capacity or attributes.
• BOM_RESOURCE_SHIFTS, BOM_SHIFT_DATES, BOM_SHIFT_TIMES — shift calendars, shift dates, and shift time windows that determine available working hours.
• MRP_NET_RESOURCE_AVAIL — the target table where computed availability is stored for planning consumption.
• MTL_PARAMETERS — organization parameters providing default calendar and planning context.
• DUAL — used for single-row arithmetic and date expressions within the PL/SQL logic.

Usage Notes

POPULATE_AVAIL_RESOURCES is typically invoked as a batch step within the capacity planning process rather than interactively. In Oracle EBS 12.1.1 and 12.2.2 it is called from concurrent programs that refresh resource availability, and it is referenced by three other packages, indicating it is a shared dependency in the capacity calculation chain. The simulation set argument allows planners to populate availability for a named planning scenario without disturbing the live schedule. Developers extending capacity functionality may call CALC_RES_AVAIL for targeted single-resource refreshes, while POPULATE_AVAIL_RESOURCES is used for organization-wide or simulation-wide recalculation. Because the package header dates from 2005 and carries a "noship" source tag, custom code should treat it as an internal, version-sensitive API and avoid relying on its implicit behavior across releases. Callers should always supply explicit start and cutoff dates when a bounded planning horizon is required.