Search Results add_planned_mrs




Overview
Explore in AI Chat

Overview

APPS.AHL_AVF_PRIM_VSTS_PVT is a private PL/SQL package within the Oracle E-Business Suite Enterprise Asset Management (eAM) module, specifically belonging to the Asset Lifecycle Hub (AHL) schema. Its name—AHL_AVF_PRIM_VSTS_PVT—indicates its role in the AutoVisit framework (AVF), handling the creation and processing of "primary" visits. The suffix "_PVT" classifies it as a private API (per ETRM API classification), meaning it is intended for internal consumption by the AutoVisit engine and its public wrapper packages rather than for direct invocation by external custom code. The package is declared with AUTHID CURRENT_USER, so it executes with the privileges of the calling user, which is typical of EBS private packages that rely on APPS synonym access to the underlying AHL tables. Its core business function is to generate, manage, and cancel maintenance visits derived from maintenance requirements, master configurations, and unit effectivity data. These visits represent scheduled field service or preventive maintenance activities, and the package automates what would otherwise be manual visit-planning work.

Key Procedures and Functions

The documented package exposes four procedures:

  • ADD_PLANNED_MRS — Adds planned maintenance requirements to existing visits. It accepts either a visit identifier or a snapshot identifier (one of the two is required) so that planned MRs can be attached to a specific visit or to a set of visits derived from a planning snapshot.
  • CANCEL_VISITS — Cancels existing visits based on the master configuration supplied and the date ranges provided by the user. A snapshot identifier is the required input parameter, ensuring cancellations are scoped to a defined planning snapshot.
  • CREATE_PRIMARY_VISITS — Creates the primary visits that anchor the AutoVisit hierarchy. This is the procedure most directly associated with the user's search term "create_primary_visits," and it forms the entry point for generating top-level visit records from configuration, effectivity, and maintenance requirement data.
  • PROCESS_PRIMARY_VISITS — Processes the primary visits after creation, handling downstream logic such as task generation, hierarchy relationships, and status transitions associated with the visits.

All four follow standard EBS API conventions, including API version, initialization of the message list, commit control, validation level, and standard return status/message-count/message-data out parameters.

Tables Accessed

The package reads and writes a range of AHL tables through APPS synonyms. Visit records themselves are stored in AHL_VISITS_B, with associated tasks in AHL_VISIT_TASKS_B and visit classification in AHL_VISIT_TYPES_B. The AutoVisit hierarchy and its planning snapshots are represented by AHL_AUTOVISIT_HIERARCHY and AHL_AUTOVST_SNPSHT_HDR. Maintenance requirements and their organizational associations come from AHL_MR_HEADERS_B and AHL_MR_ORGANIZATIONS. Master configuration data is held in AHL_MC_HEADERS_B, fleet information in AHL_FLEET_HEADERS_B, unit configuration in AHL_UNIT_CONFIG_HEADERS, and unit effectivity in AHL_UNIT_EFFECTIVITIES_B. Relationships between units and other entities are captured in AHL_UE_RELATIONSHIPS. Together these tables supply the configuration, requirement, hierarchy, and effectivity inputs needed to create and process visits.

Usage Notes

As a private package, AHL_AVF_PRIM_VSTS_PVT is not documented as being referenced by any other package, and it exposes no public wrapper in the ETRM metadata. It is therefore invoked indirectly through the AutoVisit concurrent programs, forms, or engine flows that drive visit planning in eAM. The presence of commit and validation-level parameters suggests it may be called in both interactive and batch contexts, with the calling program controlling transaction boundaries. Because it is a PVT package, direct custom invocation is discouraged; customizations should use the supported public AutoVisit APIs. ETRM confirms the same signature set in both 12.1.1 and 12.2.2, so the package's behavior is consistent across these releases.