Results for “is_unit_locked”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The APPS.AHL_PRD_UTIL_PKG package body is a utility package within the Oracle Enterprise Asset Management (eAM) / Asset Lifecycle Management (ALM) module of Oracle E-Business Suite 12.1.1 and 12.2.2. It provides the central validation and derivation logic used throughout the production, work order, and maintenance management functionality of the AHL (Asset Lifecycle) schema. Its primary responsibility is to enforce business rules governing work orders, work order operations, resource assignments, parts changes, material statuses, and locator validity before transactions are committed to the database. The package is classified as OTHER in the ETRM API classification, indicating it is an internal utility layer rather than a public integration API. It is a VALID object in the APPS schema and is referenced by approximately twenty other packages, confirming its role as a foundational dependency for higher-level AHL private APIs such as AHL_PRD_PARTS_CHANGE_PVT, AHL_PRD_WO_LOGIN_PVT, and AHL_UTIL_UC_PKG.

Key Procedures and Functions

The package exposes twenty-five documented procedures and functions, which fall into three functional groups.

• Validation routines: VALIDATE_LOCATORS, VALIDATE_CONDITION, VALIDATE_REASON, and VALIDATE_MATERIAL_STATUS verify that user-supplied inventory locators, condition codes, transaction reasons, and material statuses are legitimate and permitted before a transaction or work order operation proceeds.
• State and eligibility checks: IS_UNIT_LOCKED, IS_WO_UPDATABLE, IS_OP_UPDATABLE, IS_MR_QA_ENABLED, IS_PARTCHANGE_ENABLED, ISDELASG_ENABLED, IS_WO_COMPLETABLE, IS_RESTXN_ALLOWED, and IS_WO_CANCEL_ALLOWED return Boolean-style flags that determine whether a given unit, work order, or operation may be modified, completed, cancelled, or have resources assigned or deleted. These functions encapsulate the conditional logic that forms and concurrent programs use to enable or disable actions.
• Derivation and aggregation routines: GET_OP_TOTALHOURS_ASSIGNED, GET_RES_TOTALHOURS_ASSIGNED, GET_OP_TRANSACTED_HOURS, GET_RES_TRANSACTED_HOURS, GET_OP_ASSIGNED_START_DATE, GET_OP_ASSIGNED_END_DATE, and HR_TO_DURATION compute assigned and transacted labor hours, derive operation start and end dates from assignments, and convert hours into duration values used in scheduling and cost calculations.

Tables Accessed

The package reads and writes across the core AHL, WIP, and INV tables accessed through APPS synonyms.

• AHL transactional tables: AHL_WORKORDERS, AHL_WORKORDER_OPERATIONS, AHL_WORK_ASSIGNMENTS, AHL_OPERATION_RESOURCES, AHL_RT_OPER_RESOURCES, AHL_RESOURCES, and AHL_RESOURCE_MAPPINGS supply the work order, operation, resource, and assignment data used by the eligibility and hour-derivation logic.
• AHL configuration and maintenance tables: AHL_UNIT_CONFIG_HEADERS, AHL_UNIT_EFFECTIVITIES_B, AHL_VISITS_B, AHL_VISIT_TASKS_B, and AHL_MR_HEADERS_B support unit lock checks, effectivity checks, and maintenance requirement evaluations.
• Inventory and WIP tables: MTL_MATERIAL_STATUSES and MTL_SECONDARY_INVENTORIES back the material status and locator validations, while BOM_RESOURCES provides resource definitions. Supporting references include WIP_DISCRETE_JOBS, WIP_OPERATIONS, WIP_OPERATION_RESOURCES, WIP_TRANSACTIONS, and WIP_COST_TXN_INTERFACE for cost and transaction interfaces.

Usage Notes

AHL_PRD_UTIL_PKG is an internal utility layer rather than a directly callable public API. It is invoked indirectly by AHL forms, concurrent programs, and higher-level private APIs (such as AHL_PRD_PARTS_CHANGE_PVT and AHL_PRD_WO_LOGIN_PVT) that require consistent validation of work order state, resource assignment, and material status. Custom code extending eAM production or work order functionality should preferably call the documented higher-level private APIs rather than this package directly, to preserve upgrade safety. Where direct invocation is necessary, callers should use the FND_API and FND_MESSAGE error-handling conventions that this package depends on, and should note that the package is not referenced by any database object while itself referencing roughly thirty objects, confirming its position as a low-level dependency in the AHL call stack.