Results for “msc_routing_operations_v”

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

Overview

MSC_ROUTING_OPERATIONS_V is an APPS-owned view in Oracle Advanced Supply Chain Planning (MSC) that exposes every operation belonging to a routing as it is represented within the planning schema. It is a denormalized reporting and integration interface: rather than requiring the caller to join routing headers, operation components, bill components, and lookup tables, the view presents a single, query-ready row per operation with descriptive names already resolved through the MSC_GET_NAME package. In Oracle EBS 12.1.1 and 12.2.2 the object is documented as VALID, and its status as a view rather than a table means it carries no independent storage; it is a read-only projection of the collected planning data.

The view retrieves values for planning context (PLAN_ID, SR_INSTANCE_ID, ORGANIZATION_ID), routing context (ROUTING_SEQUENCE_ID, ALTERNATE_ROUTING_DESIGNATOR, LINE_ID), item context (INVENTORY_ITEM_ID, USING_ASSEMBLY_ID), and operation attributes such as sequence number, description, department, yield, durations, and unit of measure. This makes it a convenient source for custom reports, data extracts, and integration queries that need routing operation detail without duplicating the underlying join logic.

Underlying Base Objects

The ETRM 12.2.2 metadata lists the following referenced objects: MFG_LOOKUPS (VIEW), MSC_BOM_COMPONENTS (SYNONYM), MSC_GET_NAME (PACKAGE), MSC_OPERATION_COMPONENTS (SYNONYM), MSC_ROUTINGS (SYNONYM), and MSC_ROUTING_OPERATIONS (SYNONYM).

The FROM clause joins MSC_BOM_COMPONENTS, MSC_ROUTINGS, MSC_OPERATION_COMPONENTS, and MSC_ROUTING_OPERATIONS, with MFG_LOOKUPS supplied for lookup decoding. The join keys are PLAN_ID, SR_INSTANCE_ID, and ORGANIZATION_ID, which together identify the planning instance, plus BILL_SEQUENCE_ID, COMPONENT_SEQUENCE_ID, ROUTING_SEQUENCE_ID, and OPERATION_SEQUENCE_ID, which link component, routing, and operation records into a coherent hierarchy. MSC_GET_NAME is invoked repeatedly as a scalar function package to resolve organization codes, item names, alternate BOM designators, department codes, and lookup meanings, avoiding additional joins to name-bearing tables. Because several of the referenced objects are synonyms, physical resolution depends on the planning schema objects installed in the environment.

Key Columns

• PLAN_ID, SR_INSTANCE_ID, ORGANIZATION_ID — planning context: the plan, source instance, and organization for the row.
• ROUTING_SEQUENCE_ID, ALTERNATE_ROUTING_DESIGNATOR, LINE_ID — identify the routing and its line. LINE_ID is passed to MSC_GET_NAME.DEPARTMENT_CODE to return the line's department.
• INVENTORY_ITEM_ID, USING_ASSEMBLY_ID — the assembly and using assembly, each rendered as a name by MSC_GET_NAME.ITEM_NAME.
• OPERATION_SEQUENCE_ID, OPERATION_SEQ_NUM — operation identity and displayed sequence.
• OPERATION_DESCRIPTION, OPERATION_TYPE — operation text and its decoded BOM_OPERATION_TYPE meaning via MSC_GET_NAME.LOOKUP_MEANING.
• DEPARTMENT_ID, DEPARTMENT_CODE — performing department.
• YIELD, CUMULATIVE_YIELD, REVERSE_CUMULATIVE_YIELD, NET_PLANNING_PERCENT — planning yield factors used in capacity and lead-time calculations.
• SETUP_DURATION, TEAR_DOWN_DURATION, OPERATION_LEAD_TIME_PERCENT, UOM_CODE — timing and measurement attributes.
• MINIMUM_TRANSFER_QUANTITY, FROM_UNIT_NUMBER, TO_UNIT_NUMBER, OPTION_DEPENDENT_FLAG — transfer quantity and unit-range constraints.
• EFFECTIVITY_DATE, DISABLE_DATE — effective dating window for the operation.
• USE_IN_PLAN — the column the user searched on. It is rendered through a DECODE against MFG_LOOKUPS, returning the lookup MEANING when populated and NULL when the source value is NULL. This indicates whether the operation is considered by the plan.
• STANDARD_OPERATION_CODE, BILL_SEQUENCE_ID — standard operation reference and the bill sequence linking the operation to its BOM.

Common Use Cases and Queries

Typical scenarios include validating that planned routings contain the expected operations, extracting operation-level detail for lead-time analysis, and filtering operations by whether they participate in the plan. The following query demonstrates filtering on the search term:

SELECT organization_id,
       inventory_item_id,
       operation_seq_num,
       operation_description,
       department_code,
       yield,
       setup_duration,
       uom_code,
       use_in_plan
  FROM apps.msc_routing_operations_v
 WHERE plan_id = :p_plan_id
   AND organization_id = :p_org_id
   AND use_in_plan IS NOT NULL
 ORDER BY inventory_item_id, operation_seq_num;

A second pattern joins the view to a source of item names or uses the already-resolved name columns to report all operations for an assembly across routings. Because the view includes PLAN_ID and SR_INSTANCE_ID, results can be scoped to a single plan and instance, which is essential when multiple plans or instances share the same organization identifiers. Queries should always filter on these planning keys to avoid cross-plan duplication, and callers should be aware that repeated MSC_GET_NAME invocations make the view heavier than a direct base-table join when only a few attributes are required.