Search Results mtl_routing_rev_highdate_v




Overview
Explore in AI Chat

Overview

MTL_ROUTING_REV_HIGHDATE_V is an Oracle E-Business Suite view owned by the APPS schema and classified under the INV (Inventory) product family. The ETRM metadata explicitly documents its description as "10SC ONLY," indicating that the object is intended exclusively for the Discrete Manufacturing (10SC) industry/legislation configuration rather than for general-purpose use across all EBS installations. The view encapsulates revision date-range logic for routing item revisions, deriving a "high date" boundary for each revision record.

The view's role in reporting and integration centers on providing a complete, query-friendly picture of the effective lifespan of a manufacturing routing revision. Rather than requiring downstream consumers to compute revision expiry windows themselves, the view exposes a synchronized pairing of low and high dates for every (organization, item, process revision) combination. Because it is a view and not a table, it introduces no storage overhead and always reflects the current state of the underlying revision records.

Underlying Base Objects

According to the documented view text, MTL_ROUTING_REV_HIGHDATE_V is defined solely over MTL_RTG_ITEM_REVISIONS, which is referenced through a SYNONYM in the same schema. The view performs a self-join of this base object, aliased as REV1 and REV2:

  • REV1 supplies the anchor row — the organization, item, process revision, effectivity date, and implementation date of the revision being reported.
  • REV2 provides the next-greater effectivity date, joined using outer-join syntax (REV2.EFFECTIVITY_DATE(+) > REV1.EFFECTIVITY_DATE) on ORGANIZATION_ID and INVENTORY_ITEM_ID.

The outer join ensures that the latest revision for an item is not dropped when no subsequent revision exists. The join is grouped by the REV1 attributes, collapsing the qualifying REV2 rows into a single aggregate per revision, from which the high date is computed.

Key Columns

  • ORGANIZATION_ID — The inventory organization that owns the routing revision.
  • INVENTORY_ITEM_ID — The item whose routing revision record is being described.
  • PROCESS_REVISION — The revision code/identifier applied to the routing; this is the column most closely associated with the user's search term "process_revision."
  • EFFECTIVITY_DATE — The date on which the revision becomes effective (the low boundary).
  • HIGH_DATE — Derived as NVL(MIN(REV2.EFFECTIVITY_DATE - 1/(60*60*24)), GREATEST(SYSDATE, REV1.EFFECTIVITY_DATE)). This is either one second before the next revision's effectivity date, or — when no later revision exists — the greater of the current system date and the revision's own effectivity date.
  • IMPLEMENTATION_DATE — The date the revision was implemented, carried through from the base table.

Common Use Cases and Queries

The view is principally used to enumerate routing revisions with their active windows, supporting revision history reports, as-of-date analysis, and integration extracts where a singular revision valid at a point in time must be identified.

Listing all revisions for an item:

  • SELECT organization_id, inventory_item_id, process_revision, effectivity_date, high_date, implementation_date FROM apps.mtl_routing_rev_highdate_v WHERE organization_id = :org_id AND inventory_item_id = :item_id ORDER BY process_revision, effectivity_date;

Identifying the currently effective revision for an item, where SYSDATE falls between the low and high boundaries:

  • SELECT process_revision FROM apps.mtl_routing_rev_highdate_v WHERE organization_id = :org_id AND inventory_item_id = :item_id AND :query_date BETWEEN effectivity_date AND high_date;

Because the view is documented as "10SC ONLY," deployments that do not use the Discrete Manufacturing configuration may find this object absent or non-functional. Consumers should confirm installation scope before relying on it within custom concurrent programs, BI Publisher reports, or interface extracts. Where broader availability is required, equivalent logic must be reconstructed directly against MTL_RTG_ITEM_REVISIONS.