Search Results opi_opm_common_pkg




Overview
Explore in AI Chat

Overview

APPS.OPI_OPM_COMMON_PKG is a PL/SQL package body that provides shared utility logic for the Oracle Process Manufacturing (OPM) suite within Oracle E-Business Suite 12.1.1 and 12.2.2. Its central responsibility is the retrieval and conversion of cost, currency, and resource information that is consumed by the OPM costing, capacity planning, and order management modules. The package abstracts common lookups—such as determining component costs, converting amounts across currencies, and validating resource charges—so that other OPM programs do not need to re-implement the same logic.

The object is registered in the ETRM repository as VALID, with an API classification of OTHER. It owns no external interfaces and exposes internal procedures intended primarily for reuse by other APPS schema packages. The body depends on several OPM and general ledger master tables as well as on other utility packages including GMF_CMCOMMON, GMF_GLCOMMON_DB, and STANDARD. It does not reference any user-defined types or external schemas outside of APPS and SYS.

Key Procedures and Functions

  • OPMCO_GET_COST — Returns the cost associated with an OPM entity, typically a component or item, based on the identifier supplied by the caller. This is the primary cost-retrieval entry point used by downstream costing routines.
  • OPMCO_GET_MULCURR_AMT — Retrieves an amount that may be expressed in multiple currencies, providing callers with the ability to work with foreign-currency values stored in OPM transaction and master data.
  • OPMCO_CURRCONV_ERROR — Provides error-handling behaviour for currency conversion failures. It is invoked when a conversion rate cannot be resolved or when the source/target currency pair is invalid, allowing the calling program to report a consistent error.
  • OPI_OPM_GET_CHARGE — Returns charge information for an OPM resource or operation. This is commonly used in capacity and resource-cost calculations where a resource carries associated charge rates.
  • OPMCO_GET_RSRC_COST — Returns the cost of a resource as defined in the OPM resource master. It is used by capacity planning and production costing to value resource usage.

The documented metadata lists seven procedures and functions in total; the five above are the explicitly named entries. The remaining routines follow the same naming conventions and support the shared cost/currency/resource functions described.

Tables Accessed

The package reads from and writes to the following OPM, general ledger, and inventory master tables, accessed through APPS synonyms:

  • CM_CMPT_DTL and CM_RSRC_DTL — Component and resource detail tables that hold cost and charge breakdowns.
  • CR_RSRC_MST — Resource master, the source of resource rates and definitions.
  • CM_CLDR_DTL and CM_CLDR_HDR — Calendar detail and header tables, used to align cost and resource calculations with production calendars.
  • GL_CURR_MST, GL_PLCY_MST, and GL_SRCE_MST — General Ledger currency, policy, and source masters, used for currency conversion and rate resolution.
  • IC_ITEM_MST and IC_WHSE_MST — Inventory item and warehouse masters, providing item and organisation context for cost lookups.
  • OP_ORDR_DTL — Order detail, linked to production and resource usage.
  • SY_ORGN_MST — Organisation master, providing the operating unit context for multi-organisation queries.

Usage Notes

OPI_OPM_COMMON_PKG is an internal utility package rather than a directly invoked concurrent program or form-level API. It is invoked by other PL/SQL packages within the OPM module—six documented packages reference it—whenever cost, currency, or resource values must be resolved.

Typical invocation contexts include OPM costing and capacity programs, resource and component cost rollups, and any custom extension that needs to convert an OPM amount between currencies or validate a currency-conversion error condition. Because the package is classified as OTHER and is not referenced by any database object outside its own dependencies, it should be treated as an internal implementation detail. Custom code that relies on it must account for the possibility that individual procedure signatures differ between 12.1.1 and 12.2.2, and should therefore query the data dictionary for the exact signature in the target instance rather than assuming cross-release stability.