Results for “msc_resource_requirements_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

MSC_RESOURCE_REQUIREMENTS_V is a reporting and integration view owned by the APPS schema in Oracle Advanced Supply Chain Planning (MSC). In Oracle EBS 12.1.1 and 12.2.2 it exposes the planned resource requirements generated by the planning engine — the load that scheduled operations place on departments, resources, and machines across a plan. Each row represents a single resource requirement tied to a supply (a planned order, discrete job, repetitive schedule, or similar), quantified in resource hours and units, and positioned in time through start and end dates.

Because the view resolves internal surrogate identifiers into human-readable codes, it is widely used for capacity reporting, resource loading analysis, and integration of plan output into custom dashboards or downstream systems. It is particularly relevant to investigations of overloaded capacity: the overloaded_capacity condition in Advanced Supply Chain Planning arises when resource requirements within a bucket exceed available resource capacity, and this view supplies the requirement-side figures needed to identify and quantify that condition. The view is read-only and does not maintain data; it presents the contents of the underlying planning tables at query time.

Underlying Base Objects

The view is defined over the following documented base objects, most of which are accessed through synonyms in the APPS schema: MSC_RESOURCE_REQUIREMENTS, MSC_RESOURCE_INSTANCE_REQS, MSC_DEPARTMENT_RESOURCES, MSC_JOB_OPERATIONS, MSC_JOB_OP_RESOURCES, MSC_SUPPLIES, MSC_ITEMS, MSC_SYSTEM_ITEMS, MSC_INTERORG_SHIP_METHODS, and the MSC_GET_NAME package.

MSC_RESOURCE_REQUIREMENTS is the primary source of rows. It is joined to planning supply information in MSC_SUPPLIES and to item definitions in MSC_ITEMS and MSC_SYSTEM_ITEMS, allowing each requirement to carry the planned item, the source item, and the supply that drives demand for the resource. Department and resource definitions flow from MSC_DEPARTMENT_RESOURCES, while routing information in MSC_JOB_OPERATIONS and MSC_JOB_OP_RESOURCES supplies operation sequence, efficiency, utilization, and routing attributes used in the calculated hour columns. MSC_RESOURCE_INSTANCE_REQS and MSC_INTERORG_SHIP_METHODS support resource instances and inter-organization shipping logic. The MSC_GET_NAME package supplies the decoding functions that translate numeric IDs into organization, department, and resource codes, and that resolve lookup meanings.

Key Columns

• TRANSACTION_ID, PLAN_ID, ORGANIZATION_ID, SR_INSTANCE_ID — identity and context of the requirement, including the plan and source instance.
• DEPARTMENT_ID, RESOURCE_ID — the department and resource being loaded, decoded through MSC_GET_NAME.DEPARTMENT_CODE and RESOURCE_CODE for reporting.
• START_DATE / END_DATE and FIRM_START_DATE / FIRM_END_DATE — the view returns NVL(FIRM_START_DATE, START_DATE) and NVL(FIRM_END_DATE, END_DATE), giving the effective scheduling window used for bucketing.
• RESOURCE_HOURS and DAILY_RESOURCE_HOURS — the core load figures; both return NULL when RESOURCE_HOURS is zero. Adjusted hours are computed using MDR.EFFICIENCY and MDR.UTILIZATION (×0.0001), so the requirement reflects effective capacity consumption.
• INVENTORY_ITEM_ID, ITEM_NAME, SOURCE_ITEM_ID — the planned item and its source item.
• SUPPLY_ID, ORDER_NUMBER/WIP_ENTITY_NAME — the supply driving the requirement, with the display value falling back to TRANSACTION_ID.
• OPERATION_SEQ_NUM, RESOURCE_SEQ_NUM, BATCH_NUMBER — routing and batch positioning.
• LOAD_RATE, ASSIGNED_UNITS, YIELD, REVERSE_CUMULATIVE_YIELD — rate and yield characteristics of the resource assignment.
• FIRM_FLAG and its lookup meaning, STATUS, APPLIED — state indicators; STATUS and APPLIED are commonly filtered to isolate firmed or applied requirements.
• NEW_SCHEDULE_DATE, NEW_ORDER_QUANTITY, DAILY_RATE, LAST_UNIT_COMPLETION_DATE — scheduling attributes inherited from the supply.

Common Use Cases and Queries

The principal use case is capacity and overload analysis. Requirements are aggregated by resource and time bucket, then compared with resource capacity to detect overloaded_capacity conditions. A representative query lists loads for a plan:

• SELECT plan_id, organization_id, department_id, resource_id, resource_hours, daily_resource_hours, start_date FROM msc_resource_requirements_v WHERE plan_id = :plan_id AND resource_hours > 0 ORDER BY resource_id, start_date;
• SELECT resource_id, TRUNC(start_date) load_date, SUM(resource_hours) total_hours FROM msc_resource_requirements_v WHERE plan_id = :plan_id GROUP BY resource_id, TRUNC(start_date) ORDER BY resource_id, load_date;
• SELECT department_id, resource_id, order_number, item_name, resource_hours FROM msc_resource_requirements_v WHERE plan_id = :plan_id AND firm_flag = 1 AND start_date BETWEEN :from_date AND :to_date;

These patterns support overload identification, finite capacity review, and export of plan resource data to external scheduling or MES systems. Joining the aggregated output to capacity tables or the planning resource summary enables flagging of buckets where summed resource hours exceed available capacity.