Search Results ahl_mr_effectivities_s

Overview

The APPS.AHL_FMP_MR_EFFECTIVITY_PVT package body is a private (PVT) PL/SQL API within the Oracle E-Business Suite Enterprise Asset Management (EAM) module, specifically the Asset Lifecycle / Maintenance Management (AHL) schema. It forms part of the Maintenance Requirement (MR) framework, which allows organizations to define, schedule, and apply maintenance rules against assets and positions. The package encapsulates the business logic governing "effectivities" — the records that determine which maintenance requirements apply to a given asset, item, or position, and over what time interval or condition. As a PVT package it is not intended for direct customer invocation; instead it supplies the internal engine consumed by the public maintenance-requirement APIs and by the Maintenance Requirement workbench. Its central role is to process effectivity data, evaluating and persisting the associations that link maintenance headers, detail lines, and intervals to the applicable assets. The parameter naming convention (MR, EFFECTIVITY) confirms its scope is the maintenance requirement effectivity subsystem rather than the broader asset hierarchy.

Key Procedures and Functions

The documented package exposes a single public entry point at the metadata level:

• PROCESS_EFFECTIVITY — the core procedure that drives effectivity processing. It evaluates the effectivity rules for a maintenance requirement, resolves the applicable assets or items through the supporting views, and writes the resulting effectivity records and their detail children. The procedure also integrates validation and error handling by calling FND_API, FND_MSG_PUB, and FND_MESSAGE, and it emits diagnostic traces through AHL_DEBUG_PUB. Parameter lists are not disclosed in the documented metadata and should not be assumed.

Because the package is classified PVT, additional internal helper routines may exist but are not part of the documented public surface. References to AHL_FMP_COMMON_PVT indicate shared utilities from the Flow Manufacturing / Maintenance Processing common layer are reused.

Tables Accessed

The package reads and writes the following documented tables and views through APPS synonyms:

• AHL_MR_EFFECTIVITIES / AHL_MR_EFFECTIVITIES_S / AHL_MR_EFFECTIVITIES_V / AHL_MR_EFFECTIVITIES_APP_V — the base table, its sequence-backed surrogate key support, and the validation views used to enforce the entity's business rules. AHL_MR_EFFECTIVITIES_S is the primary target of the user's search, confirming it is the effectivity header store.
• AHL_MR_EFFECTIVITY_DTLS / AHL_MR_EFFECTIVITY_DTLS_APP_V — child detail rows describing individual effectivity attributes or conditions.
• AHL_MR_HEADERS_B — the base maintenance requirement header that the effectivity qualifies.
• AHL_MR_INTERVALS / AHL_MR_INTERVALS_APP_V — interval definitions tied to the requirement, used to time-bound effectivity.
• AHL_POSITION_ALTERNATES_V — position alternate view, used to resolve asset/position context.
• MTL_SYSTEM_ITEMS_KFV — the item key flexfield view, providing item validation and descriptive context.
• FND_LOOKUP_VALUES_VL, FND_PROFILE, FND_GLOBAL — configuration, profile option, and session context retrieval.
• PLITBLM — the standard PL/SQL index-by table used for bulk processing.

Usage Notes

AHL_FMP_MR_EFFECTIVITY_PVT is invoked indirectly rather than directly by end users. Typical call paths include the Maintenance Requirement workbench forms, EAM concurrent programs that generate or refresh maintenance requirement effectivities, and the public maintenance-requirement APIs that delegate effectivity handling to this private layer. Customizations should never call the PVT package directly; developers integrating with maintenance requirement effectivity should target the corresponding public API. The package depends on FND_API for the standard FND_API.G_RETURN_STATUS error convention and on FND_MSG_PUB for message stack integration, so callers must inspect the message stack on failure. For troubleshooting, enabling AHL_DEBUG_PUB tracing is the recommended diagnostic technique in both 12.1.1 and 12.2.2, as the object's dependency set is identical across those releases.