Search Results insert_tasks

Overview

APPS.AHL_VWP_RULES_PVT is a private PL/SQL package in the Oracle E-Business Suite Discrete Manufacturing / Complex Maintenance, Repair and Overhaul (CMRO) product family, specifically within the Visit Work Package (VWP) module. Its stated purpose in the package header is to serve as a Private API for managing Planning → Visit Work Package → VISIT, TASKS, PROJECT, PRODUCTION, PRICING and COSTING related rules as procedural logic. In effect, it centralizes the validation, lookup, and derivation logic that the VWP planning layer relies on when resolving user-entered identifiers, propagating visit and task hierarchies, and seeding work requirements. The package is classified as a Private (PVT) API, meaning it is not intended for direct invocation by external or customer-written code; it is a supporting component behind the public VWP APIs, the Oracle Forms user interface, and concurrent processing logic. The header date of 2007 and the 11.5.10 change note confirm the package originates in the R12-era codebase and is carried forward unchanged into 12.1.1 and 12.2.2.

Key Procedures and Functions

The documented interfaces fall into three broad categories: cross-entity identity resolution, structural validation, and task creation/derivation.

• Identity resolution ("Check_…_Name_Or_Id") routines: CHECK_ITEM_NAME_OR_ID, CHECK_SERIAL_NAME_OR_ID, CHECK_ORG_NAME_OR_ID, CHECK_DEPT_DESC_OR_ID, CHECK_SR_REQUEST_NUMBER_OR_ID, CHECK_VISIT_TASK_NUMBER_OR_ID, CHECK_LOOKUP_NAME_OR_ID, and CHECK_PROJECT_TEMPLATE_OR_ID. These accept either a descriptive name/number or a surrogate identifier and normalize it to the corresponding internal ID, returning or raising exceptions on ambiguity or invalid input.
• Contextual validators: CHECK_VISIT_IS_SIMULATED (tests whether a visit is a simulated/what-if visit), CHECK_PROJ_RESPONSIBILITY (verifies project responsibility authority), CHECK_SERIAL_NO_BY_UCONFIG (validates serial against a unit configuration), INSTANCE_IN_CONFIG_TREE (confirms an instance exists within a configuration hierarchy), CHECK_COST_PARENT_LOOP and CHECK_ORIGIN_TASK_LOOP (detect circular parent/origin relationships before they are persisted).
• Retrieval functions: GET_SERIAL_ITEM_BY_UNIT, GET_COST_ORIGINATING_ID, GET_VISIT_TASK_ID, and GET_VISIT_TASK_NUMBER return derived values used by callers that already hold a partial key.
• Task generation routines: INSERT_TASKS, CREATE_TASKS_FOR_MR, and TECH_DEPENDENCY build visit task rows, including tasks generated for a maintenance request, and apply technical dependency ordering among tasks.

Tables Accessed

The package reads and writes through APPS synonyms. Visit and stage structure is handled via AHL_VISITS_B, AHL_VISIT_TASKS_B, AHL_VISIT_TASKS_B_S, AHL_VWP_STAGES_B, and AHL_VISIT_STAGE_TYP_ASOC. Task relationship data is stored in AHL_TASK_LINKS and AHL_TASK_LINKS_S. Maintenance request data comes from AHL_MR_HEADERS_B, AHL_MR_RELATIONSHIPS, and AHL_MR_ROUTES, with route definitions in AHL_ROUTES_B. Instance and configuration validation uses CSI_ITEM_INSTANCES, AHL_UNIT_CONFIG_HEADERS, and AHL_UNIT_EFFECTIVITIES_B. Department shift data is drawn from AHL_DEPARTMENT_SHIFTS when visit scheduling or responsibility checks are performed.

Usage Notes

Because the package is a private API, it is not documented for direct customer invocation. It is normally reached indirectly when users create or modify visits and visit tasks in the Visit Work Package forms, when the Create Tasks for Maintenance Request process is executed, and when planning rules are evaluated during visit simulation. The dependency metadata shows the package is referenced by 22 other packages, which confirms its role as a shared internal service layer. Customizations should target the public VWP APIs or use supported extension hooks rather than calling AHL_VWP_RULES_PVT directly, since the private interface may change between releases without notice.