Results for “bomfv_work_order_rtg_opratns”

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

Overview

BOMFV_WORK_ORDER_RTG_OPRATNS is a read-only view owned by the APPS schema in Oracle E-Business Suite, registered under the Bills of Material (BOM) product family. ETRM classifies the object as retrofitted, meaning it was introduced or re-pointed to preserve compatibility with older forms, reports, or integration interfaces that reference a legacy name. The view presents work order routing operations — the discrete manufacturing steps that an assembly passes through on the shop floor — in a denormalized, user-facing form suitable for reporting and external integration.

Its defining characteristic is that it flattens the relationship between a routing header (BOM_OPERATIONAL_ROUTINGS) and its operation sequences (BOM_OPERATION_SEQUENCES), while resolving foreign-key identifiers into meaningful codes and names. It also filters to a specific class of routing, returning only common routings (CFM_ROUTING_FLAG = 2 or NULL) and standard operation types (OPERATION_TYPE IS NULL or 1). The view is declared WITH READ ONLY, so it can be queried but never used as a DML target.

Underlying Base Objects

ETRM documents seven referenced base objects, all accessed through APPS synonyms:

• BOM_OPERATIONAL_ROUTINGS — routing header, supplying the assembly item, organization, and common routing sequence identifier.
• BOM_OPERATION_SEQUENCES — the detailed routing steps, joined on ROUTING_SEQUENCE_ID.
• BOM_STANDARD_OPERATIONS — outer-joined source of the operation code.
• BOM_DEPARTMENTS — department code for each sequence.
• MTL_PARAMETERS — organization parameters, used to derive the organization code.
• MTL_SYSTEM_ITEMS — item master, joined by inventory item and organization.
• HR_ALL_ORGANIZATION_UNITS — organization name.

Only BOM_STANDARD_OPERATIONS is outer-joined; the remaining joins are inner, so a routing operation will not appear unless its department, organization, and item rows all exist. Organization-level security is enforced through a bind placeholder on OP.ORGANIZATION_ID.

Key Columns

• SEQUENCE_NUMBER — operation sequence number from BOM_OPERATION_SEQUENCES; the ordering key within the routing.
• START_EFFECTIVE_DATE — the sequence effectivity date, marking when the operation becomes valid.
• END_EFFECTIVE_DATE — mapped from SQ.DISABLE_DATE. This is the column most often targeted by users searching for "end_effective_date"; it represents the date on which the routing operation is disabled. A NULL value indicates the operation remains active indefinitely.
• ORGANIZATION_CODE / ORGANIZATION_NAME — from MTL_PARAMETERS and HR_ALL_ORGANIZATION_UNITS respectively.
• ALTERNATE_ROUTING_CODE — the alternate routing designator from the routing header.
• OPERATION_CODE / DEPARTMENT_CODE — standard operation and department identifiers.
• OPERATION_YIELD, MINIMUM_TRANSFER_QUANTITY, OPERATION_LEAD_TIME_PERCENT — shop-floor execution attributes.
• ROUTING_SEQUENCE_ID, OPERATION_SEQUENCE_ID, STANDARD_OPERATION_ID, DEPARTMENT_ID — surrogate keys preserved for joins back to base tables.
• UPDATED_ON, UPDATED_BY, CREATED_ON, CREATED_BY — audit columns.
• Several underscore-prefixed columns (_KF:, _LA:, _SEC:) are Oracle Forms/Foundations control tokens rather than business data.

Common Use Cases and Queries

The view supports routing inquiries, shop-floor reporting, and interface extracts where consumers require operation effectivity windows. A typical query listing active operations for an organization, including the end effective date, is:

• SELECT organization_code, sequence_number, operation_code, start_effective_date, end_effective_date FROM bomfv_work_order_rtg_opratns WHERE organization_code = 'M1' ORDER BY sequence_number;
• SELECT * FROM bomfv_work_order_rtg_opratns WHERE end_effective_date IS NULL OR end_effective_date > SYSDATE; — returns operations still in force.
• SELECT department_code, COUNT(*) FROM bomfv_work_order_rtg_opratns GROUP BY department_code; — workload distribution by department.

Because the view is read-only and carries organization security, it is safe for ad-hoc reporting. For update requirements, base tables must be addressed directly through the Bills of Material APIs.