Search Results get_stages_details

Overview

The APPS.AHL_VWP_VISITS_STAGES_PVT package body is a private (PVT) PL/SQL API within the Oracle E-Business Suite Complex Maintenance, Repair and Overhaul (CMRO) module. Its stated purpose is to manage the Planning → Visit Work Package → Visits → Stages relationship. In operational terms, the package governs the definition, validation, and lifecycle maintenance of stages that belong to a visit within a Visit Work Package (VWP). It encapsulates the business rules that determine how stages are sequenced, how they relate to visit types and stage types, and how stage-level attributes such as dates and assigned rules are validated against the underlying maintenance data model.

The header comment indicates the package was created for Release 11.5.10 and carries a header revision from May 2005. It remains a documented object under the 12.1.1 and 12.2.2 releases, owned by APPS and classified as a private API. Because it is private, it is not intended for direct customer invocation; it is called by other packages and forms that constitute the public VWP functionality. The metadata records that nine other packages reference it, confirming its role as a shared internal engine for stage processing.

The package declares a global debug flag driven by AHL_DEBUG_PUB.is_log_enabled, a convention common to AHL (Complex Maintenance) APIs, and defines a Dept_Tbl_Type collection used to pass department identifiers into stage calculations.

Key Procedures and Functions

The documented API surface comprises sixteen procedures and functions:

• GET_STAGES_DETAILS — the routine most commonly referenced in searches; retrieves the detail set of stages associated with a given visit or visit context for display or downstream processing.
• CREATE_STAGES — inserts new stage records into the visit stages table, applying defaulting and validation.
• UPDATE_STAGES — modifies attributes of existing stages.
• DELETE_STAGES and DELETE_ALL_STAGES — remove one or all stage records tied to a visit, including dependent associations.
• VALIDATE_STAGES, VALIDATE_STAGE_UPDATES, VALIDATE_STAGE_DATES, and VALIDATE_STAGE_RULES — enforce business rules around stage content, update legality, date ranges, and rule assignment before changes are committed.
• CHECK_STAGE_NAME_OR_ID — performs duplicate and identity checks on stage name or identifier.
• PROCESS_STAGETYP_ASSOC — manages the association between a visit stage and its stage type.
• ASSOC_VISITTYPE_TO_VISIT — links a visit type definition to a specific visit, driving which stages are applicable.
• GET_VISIT_STAGE_NUMBER — returns the sequence or stage number for ordering stages within a visit.
• UPDATE_STAGES_HIERARICHY and UPDATE_STG_RUL_HIERARCHY — maintain parent/child hierarchy among stages and among stage rules.
• UPDATE_AS_STAGE_RULE_DEL — handles deletion of stage-rule assignments.
• COMPUTE_STAGE_END_DATE — derives the end date of a stage, typically from duration, shift, and calendar data.
• Default_missing_attributes — an internal defaulting routine populating omitted stage attributes from visit or type context.

Tables Accessed

The package reads and writes a set of AHL base and interface tables through APPS synonyms. AHL_VSTG_-related structures such as AHL_VWP_STAGES_B and AHL_VISIT_STAGE_TYP_ASOC (with its _S sequence-supported companion) hold the primary stage and stage-type association data. AHL_VISITS_B and AHL_VISIT_TYPES_B provide visit and visit type context, while AHL_VISIT_TYPE_STAGES_B, AHL_VST_TYP_STAGE_LINKS, and AHL_VST_TYP_STG_TYP_ASOC define the templates from which stages are generated for a visit. Hierarchy and rule processing use AHL_STAGE_LINKS, AHL_STAGE_LINKS_S, and AHL_TASK_LINKS. Task and configuration context is drawn from AHL_VISIT_TASKS_B, AHL_UNIT_CONFIG_HEADERS, and AHL_MC_HEADERS_B. Department shift and calendar calculations for end-date derivation rely on AHL_DEPARTMENT_SHIFTS.

Usage Notes

Because AHL_VWP_VISITS_STAGES_PVT is a private API, it should not be invoked directly from custom code. It is primarily called from the Visit Work Package forms and from public AHL packages that expose the supported VWP operations. Customizations requiring stage retrieval, such as reporting or integration extracts, should call the supported public wrapper rather than GET_STAGES_DETAILS or the other private routines. When validation routines are used, callers must pass the return status, message count, and message data out parameters and inspect them before committing, since the package reports errors via the standard x_return_status, x_msg_count, and x_msg_data convention. Changes to stage hierarchy or stage rules must be sequenced after base stage creation, as the hierarchy and link routines depend on existing stage identifiers.