Search Results get_mr_applicability

Overview

APPS.AHL_FMP_PVT_W is a private helper package within the Oracle E-Business Suite Enterprise Asset Management (EAM) / Asset Lifecycle family, specifically associated with the AHL (Asset Health / Maintenance Management) application schema. It is an internal "W" (wrapper) package compiled with AUTHID CURRENT_USER, meaning its internal SQL statements execute under the privileges of the calling user rather than the package owner. This design is characteristic of Oracle's Rosetta-generated interface layers, which exist to marshal complex PL/SQL collection types across call boundaries — typically between Java/BC4J middle-tier code and the database.

The package's principal business purpose is to expose maintenance requirement (MR) applicability logic. It evaluates which maintenance requirements apply to a given asset or item instance and returns the affected items and applicable MRs. The procedure name GET_MR_APPLICABILITY, which is the entry point users most commonly search for, embodies this core function: determining whether one or more maintenance requirements are applicable to a specific asset context. The package header revision ($Header: AHLWFMPS.pls 120.2.12020000.3, dated 2013/04/01) confirms it was shipped and maintained through the 12.2.x release line, and it is present in both 12.1.1 and 12.2.2 environments as an APPS-owned object.

Key Procedures and Functions

The documented interface comprises twelve procedures, organized into two functional groupings:

• GET_MR_APPLICABILITY — The primary applicability evaluator. It determines and returns the maintenance requirement applicability outcome for a given maintenance context.
• GET_APPLICABLE_MRS — Returns the set of maintenance requirements applicable to the supplied context, populating the applicable_mr_tbl_type collection.
• GET_PM_APPLICABLE_MRS — A preventative-maintenance variant that returns applicable MRs scoped to PM definitions.
• GET_MR_AFFECTED_ITEMS — Returns the item instances affected by a maintenance requirement, populating the mr_item_instance_tbl_type collection.
• ROSETTA_TABLE_COPY_IN_P1 / _P3 / _P5 / _P7 — Bulk COPY_IN marshalling procedures. Each transforms parallel JTF typed tables (JTF_VARCHAR2_TABLE_100/300/400/4000, JTF_NUMBER_TABLE) into the strongly typed PL/SQL collections consumed internally (mr_item_instance_tbl_type for P1, applicable_mr_tbl_type for P3, and so on).
• ROSETTA_TABLE_COPY_OUT_P1 / _P3 / _P5 / _P7 — The inverse operations, flattening the internal typed collections back into JTF typed tables for return across the interface boundary.

The numeric suffixes (_P1, _P3, _P5, _P7) correspond to distinct Rosetta-generated payload definitions, each handling a different record shape. Parameter lists are deliberately omitted here; each COPY_IN/COPY_OUT pair is symmetric, with COPY_OUT parameters declared as out nocopy.

Tables Accessed

Per the ETRM metadata, the package references a single table through an APPS synonym: PLITBLM. This is a JTF/PL-SQL interface staging table used to pass bulk typed-table parameters between the middle tier and PL/SQL entry points. The applicability procedures (GET_MR_APPLICABILITY, GET_APPLICABLE_MRS, GET_PM_APPLICABLE_MRS, GET_MR_AFFECTED_ITEMS) operate largely on in-memory collections marshalled by the Rosetta COPY procedures, with PLITBLM supporting the bulk transfer mechanics. No direct DML against core AHL maintenance tables is documented at this private-wrapper layer.

Usage Notes

AHL_FMP_PVT_W is a private (PVT) package and is not intended for direct customer invocation. It is referenced by zero other packages according to the metadata, indicating it is called from outside the PL/SQL layer — typically by Oracle's BC4J/Java middle-tier components serving the Maintenance Management and Asset Health pages, or by OAF-based forms and regions that evaluate maintenance applicability when an asset is queried or work is created. In EBS 12.1.1 and 12.2.2 the call path passes JTF typed tables across the JDBC boundary; the Rosetta COPY_IN/COPY_OUT procedures perform the necessary collection conversion, and the GET_* procedures execute the applicability logic. Custom code should not call this package directly, as its signature is subject to change between patch levels; any bespoke applicability requirement should instead use the supported public APIs or views in the AHL schema.