Search Results ahl_mr_pc_nodes_v




Overview

In Oracle E-Business Suite Release 12.1.1 and 12.2.2, the view APPS.AHL_MR_PC_NODES_V belongs to the AHL (Complex Maintenance Repair and Overhaul) product family. It presents a consolidated, reporting-friendly projection of Maintenance Requirement (MR) header information joined with the physical configuration node identifier defined in the MR effectivities. Maintenance Requirements in AHL describe recurring inspection, servicing, or maintenance tasks applicable to a maintainable asset or configuration, and their applicability is governed by effectivity records. The AHL_MR_PC_NODES_V view exists specifically to expose the PC_NODE_ID from the underlying effectivity data alongside descriptive MR attributes, enabling consumers to associate a Maintenance Requirement with a specific node in the physical configuration hierarchy without writing the join themselves. Its object type is VIEW, owned by the APPS schema, and its status is documented as VALID.

Underlying Base Objects

The view is defined over a join of several documented base objects. According to the ETRM metadata, the referenced objects are AHL_MR_EFFECTIVITIES (a synonym), AHL_MR_HEADERS_APP_V (a view), FND_LOOKUP_VALUES_VL (a view), and FND_PROFILE (a package). The view text confirms that AHL_MR_HEADERS_APP_V supplies the MR header attributes, AHL_MR_EFFECTIVITIES supplies the PC_NODE_ID, and three separate instances of FND_LOOKUP_VALUES_VL resolve lookup codes for program type, program subtype, and revision status. Because the description notes the view is based on a join of AHL_MR_DETAILS_V and AHL_MR_EFFECTIVITIES, the header-level MR attributes flow through the MR details projection that AHL_MR_HEADERS_APP_V also serves. The join on MR_HEADER_ID links each MR header to its effectivity record, and the predicate SYSDATE <= NVL(MR.EFFECTIVE_TO, SYSDATE) ensures only currently effective requirements are returned.

Key Columns

Common Use Cases and Queries

The view is most commonly used to report effective Maintenance Requirements together with their applicable physical configuration node, and to drive integration or validation logic that needs decoded lookup meanings instead of raw codes.

  • Listing all currently effective MRs for a given node or configuration.
  • Producing status and program-type reports where decoded meanings are required.
  • Feeding custom concurrent programs or interfaces that map requirements to configuration nodes.

A representative query follows:

SELECT mr_header_id, title, version_number, status, program_type, program_subtype, effective_from, effective_to, revision, pc_node_id FROM apps.ahl_mr_pc_nodes_v WHERE effective_from <= SYSDATE ORDER BY title;

Because the join restricts results to effectivities whose EFFECTIVE_TO is null or in the future, queries against this view automatically exclude expired requirements, which simplifies downstream reporting logic. The view does not expose outer-join protection on the effectivity side, so only MR headers with a matching effectivity record and a resolvable non-null program type and status are returned.