Search Results res_code




Overview
Explore in AI Chat

Overview

CRP_AVAILABLE_HOURS is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the Capacity (CRP) product family. The view exposes the gross available capacity of all resources across a manufacturing organization, expressed at the granularity of resource, department, organization, and date. Its status is VALID in both Oracle EBS 12.1.1 and 12.2.2, and its definition is unchanged between those releases according to the documented metadata.

The view is read-only and consolidates capacity data that is otherwise split across two distinct source views, depending on whether a resource operates on a 24-hour calendar or a more restricted one. Because it presents a uniform column set for both categories of resource, CRP_AVAILABLE_HOURS functions as a single reporting and integration point for gross capacity, shielding downstream consumers from the need to know which underlying view supplies a given resource. Within capacity planning and resource scheduling workflows it represents the top of the availability stack — the total hours a resource offers before any reduction for planned downtime, maintenance, or existing load.

Underlying Base Objects

The view is defined as a UNION ALL over two component views:

  • CRP_24HR_AVAILABLE_HOURS — supplies availability rows for resources whose capacity calendars span the full twenty-four-hour day.
  • CRP_OTHER_AVAILABLE_HOURS — supplies availability rows for all remaining resources, that is, those whose calendars are bounded by defined shift or work patterns.

Because the two branches are combined with UNION ALL and produce identical column lists, no deduplication or sorting is performed; every row from either source is preserved in the result set. The APPS owner and the two referenced views are the only documented base objects. Note that CRP_AVAILABLE_HOURS is itself a view rather than a table, so no direct DML is supported against it, and any integration must treat it strictly as a query source.

Key Columns

The view exposes ten columns, all carrying through from the two component views:

  • DEPARTMENT_ID — identifier of the department to which the resource is assigned.
  • DEPT_CODE — the department's short code, convenient for reporting joins and display.
  • DEPT_DESCRIPTION — descriptive name of the department.
  • RESOURCE_ID — identifier of the resource whose capacity is being reported.
  • RES_CODE — the resource short code.
  • RES_DESCRIPTION — descriptive name of the resource.
  • ORGANIZATION_ID — identifier of the owning inventory or manufacturing organization.
  • ORGANIZATION_CODE — the organization's short code.
  • AVAILABLE_DATE — the calendar date to which the capacity quantity applies.
  • AVAILABLE_HOURS — the gross available hours for that resource on that date.

Together, RESOURCE_ID and AVAILABLE_DATE form the practical grain of the data, with ORGANIZATION_ID and DEPARTMENT_ID providing the organizational context needed for aggregation and filtering.

Common Use Cases and Queries

Typical uses include capacity dashboards, resource utilization reporting, and inbound integration where external planning systems require a normalized feed of available hours. A standard query retrieving availability for a single organization over a date range follows:

  • SELECT resource_id, res_code, department_id, available_date, SUM(available_hours) available_hours FROM crp_available_hours WHERE organization_id = :org_id AND available_date BETWEEN :start_date AND :end_date GROUP BY resource_id, res_code, department_id, available_date ORDER BY resource_id, available_date;

For department-level aggregation, the same view supports rollups by DEPT_CODE or DEPT_DESCRIPTION. Comparing gross availability against scheduled load, or subtracting non-working time, is normally performed by joining the view to load or exception tables on RESOURCE_ID and AVAILABLE_DATE. Because the underlying definition is a UNION ALL, queries that do not filter by organization or date may return substantial volumes, particularly in environments with full 24-hour calendars, so predicate pushdown on AVAILABLE_DATE and ORGANIZATION_ID is recommended for performance.