Results for “mr_title”

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

Overview

AHL_PLANNING_FACTORS_V is an APPS-owned, VALID database view within the Oracle E-Business Suite product AHL – Complex Maintenance Repair and Overhaul. It exposes the planning factor definitions that drive the maintenance visit and resource planning engine in CMRO, resolving raw foreign-key identifiers into human-readable descriptions drawn from lookups, inventory, unit-of-measure, fleet, HR, and resource sources. Because the view performs this denormalization in a single SQL statement, it is the canonical reporting surface for planners, integration developers, and functional consultants who need to inspect or extract maintenance planning factor configurations without joining a dozen base tables manually.

The view is available in both EBS 12.1.1 and 12.2.2; the documented metadata is drawn from the ETRM 12.2.2 repository. It is not a table, so it holds no storage and carries no direct DML cost, but it does execute the concatenation, outer joins, and lookup resolution defined in its view text at query time.

Underlying Base Objects

The documented referenced objects are AHL_PLANNING_FACTORS (SYNONYM), AHL_RESOURCES_V (VIEW), AHL_FLEET_HEADERS_VL (VIEW), AHL_NR_PROFILE_HEADERS (SYNONYM), FND_LOOKUPS (VIEW), HR_ALL_ORGANIZATION_UNITS (SYNONYM), MTL_SYSTEM_ITEMS_KFV (SYNONYM), MTL_UNITS_OF_MEASURE_VL (VIEW), and the FND_GLOBAL (PACKAGE).

The driving table is AHL_PLANNING_FACTORS (aliased NPR), joined to AHL_NR_PROFILE_HEADERS on MR_TITLE, and outer-joined to AHL_RESOURCES_V on the CMRO resource name. Inventory item details are resolved through MTL_SYSTEM_ITEMS_KFV and unit-of-measure descriptions through MTL_UNITS_OF_MEASURE_VL. Operating organization names come from HR_ALL_ORGANIZATION_UNITS, and fleet names from AHL_FLEET_HEADERS_VL. Three separate outer joins to FND_LOOKUPS decode visit stage type (AHL_VWP_STAGE_TYPE), operations type (AHL_FLT_OPERATIONS_TYPE), and maintenance source type (AHL_MAINTENANCE_SOURCE_TYPE). FND_GLOBAL supplies session context such as the security group underlying SECURITY_GROUP_ID.

Key Columns

• RESOURCE_TYPE_ID, RESOURCE_TYPE, RESOURCE_ID, CMRO_RESOURCE_NAME – the resource referenced by the planning factor and its type.
• INVENTORY_ITEM_ID, CONCATENATED_SEGMENTS – the item and its flexfield-concatenated display value.
• UOM_CODE, UNIT_OF_MEASURE – unit of measure code and descriptive name.
• USAGE, VISIT_STAGE_TYPE_CODE, MEANING – usage quantity and the decoded visit stage type.
• FLEET_HEADER_ID, FLEET_NAME, OPERATING_ORG_ID, NAME – fleet and operating organization identifiers and descriptions.
• OPERATIONS_TYPE_CODE, MR_TITLE, NR_PROFILE_HEADER_ID, VISIT_TYPE_CODE – operations type, maintenance requirement profile title and identifier, and visit type.
• ITEM_RESOURCE_FLAG, SOURCE_APPLICATION, MAINTENANCE_TYPE_CODE – flags and source attributes governing how the factor is applied.
• SECURITY_GROUP_ID, LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN – standard audit and security columns.
• ATTRIBUTE_CATEGORY, ATTRIBUTE1…ATTRIBUTE15 – the descriptive flexfield segments available for customer-specific extensions.

Common Use Cases and Queries

Typical scenarios include auditing which resources and items feed a maintenance requirement profile, validating lookup decode values before go-live, and feeding external planning or scheduling systems via an interface table or API. A representative query follows:

• SELECT mr_title, cmro_resource_name, concatenated_segments, usage, unit_of_measure, fleet_name, name FROM apps.ahl_planning_factors_v WHERE mr_title = :p_title ORDER BY cmro_resource_name;
• SELECT visit_stage_type_code, meaning, COUNT(*) FROM apps.ahl_planning_factors_v GROUP BY visit_stage_type_code, meaning;
• SELECT resource_id, inventory_item_id, maintenance_type_code, source_application FROM apps.ahl_planning_factors_v WHERE item_resource_flag = 'Y';

Because the view uses outer joins to lookups and descriptive tables, rows with unresolved code values still appear with null descriptions, making it safe for completeness-driven reconciliation reports. Queries should filter on MR_TITLE or resource identifiers and rely on the underlying indexes for performance.