Search Results pa_uom




Overview
Explore in AI Chat

Overview

PA_UOM is a utility package in the Oracle Projects (PA) application schema that provides centralized unit-of-measure (UOM) handling services for the Projects suite. It abstracts the mechanics of resolving UOM information from the Oracle Inventory and Oracle Application Object Library tables, allowing Projects modules to work with a consistent unit-of-measure representation without embedding repetitive lookup logic. The package resides in the APPS schema and holds a VALID status in both 12.1.1 and 12.2.2, with dependencies only on the SYS.STANDARD library on the inbound side, confirming that its own implementation relies on standard PL/SQL constructs and the three documented base tables rather than on other Projects APIs.

Within the broader Projects architecture, PA_UOM functions as a low-level reference-data accessor. It sits beneath larger business flows such as resource planning, transaction import, and work type upgrade, each of which requires reliable UOM values and conversions but has no need to re-implement the underlying queries. The package is therefore best understood as a shared service layer for UOM resolution rather than as an API that drives business transactions on its own.

Key Procedures and Functions

The ETRM metadata documents two public program units within PA_UOM:

  • GET_UOM — The primary accessor for unit-of-measure information. It resolves a UOM value from the Inventory reference tables so that callers receive a validated, language-aware unit of measure. This is the routine most commonly consumed by dependent packages such as PA_TRX_IMPORT and PA_PLANNING_RESOURCE_PVT, where a UOM must be confirmed before a resource or transaction line is processed.
  • UPDATE_FND_LOOKUP_VALUES — A maintenance routine that writes to the FND_LOOKUP_VALUES table. Its presence indicates that PA_UOM participates in controlled updates to lookups associated with units of measure, presumably to keep Projects-specific UOM lookup configurations synchronized with the Inventory definition of the same unit.

Only these two program units are documented; no parameter signatures are published, and none should be assumed.

Tables Accessed

  • FND_LOOKUP_VALUES — The core Oracle Application Object Library lookup table. PA_UOM reads it to resolve lookup meanings and writes to it through UPDATE_FND_LOOKUP_VALUES, keeping UOM-related lookup entries aligned with the Inventory definitions.
  • MTL_UNITS_OF_MEASURE_TL — The multilingual units-of-measure table. It provides the translated UOM name and description, which is why GET_UOM can return language-sensitive results.
  • MTL_UOM_CONVERSIONS — Holds the conversion factors between units of measure. Access to this table allows PA_UOM to support callers that need to relate a transaction or resource quantity expressed in one UOM to the base UOM used by Oracle Projects.

All three tables are referenced through APPS synonyms, consistent with standard EBS coding practice and with the package's APPS schema ownership.

Usage Notes

PA_UOM is not exposed directly to end users. It is invoked programmatically by other Projects packages and by custom extensions built on the Projects data model. The documented referrers are PA_PLANNING_RESOURCE_PVT (resource planning), PA_TRX_IMPORT (transaction import into Projects), PA_WORK_TYPE_UPGRADE (work type upgrade processing), and PA_UOM itself, indicating internal reuse within the package body. Because PA_TRX_IMPORT and PA_PLANNING_RESOURCE_PVT are themselves invoked from concurrent programs and Oracle Forms-based flows, PA_UOM is exercised during bulk imports and resource planning runs rather than interactively.

Technical consultants extending Projects functionality should treat PA_UOM as the supported entry point for UOM resolution instead of querying MTL_UNITS_OF_MEASURE_TL or FND_LOOKUP_VALUES directly, since the package applies the appropriate Projects-side filtering and lookup logic. Care should be taken with UPDATE_FND_LOOKUP_VALUES, as any routine that modifies FND_LOOKUP_VALUES affects shared reference data and should be invoked only in the supported upgrade or configuration context for which it was designed.