Search Results c_fndcommon
Overview
INV_MEANING_SEL is a foundational PL/SQL package in the APPS schema of Oracle E-Business Suite (12.1.1 and 12.2.2) whose central purpose is the resolution of "meaning" values from coded identifiers. In the Oracle EBS data model, transactional and setup tables store short, machine-readable codes — lookup codes, unit of measure codes, status codes, hazard class codes, and so on. The corresponding human-readable descriptions are held in separate translation or lookup tables. INV_MEANING_SEL encapsulates the recurring logic required to translate those codes into their displayable meanings, returning values suitable for use in views, forms, and reports.
The package is classified as OTHER (a utility/library package rather than a public API), and its own name appears in its dependency list, consistent with the presence of both a specification and a body. Its documented status is VALID in the ETRM repository, and it is referenced by a modest set of dependent objects, confirming that it functions as a shared service layer rather than a top-level integration point. The package depends only on SYS.STANDARD, meaning it has no outward dependency on other application packages — a deliberately self-contained design that minimizes the risk of invalidation cascades.
Key Procedures and Functions
The ETRM metadata documents 25 procedures and functions. The majority are accessor functions that return the descriptive meaning for a supplied organizational code. The documented members include:
- Lookup resolvers — C_LOOKUPS, C_FND_LOOKUP, C_FND_LOOKUP_VL, C_FNDCOMMON: return lookup meanings from the FND lookup infrastructure, including the view-based (VL) variant.
- Unit of measure resolvers — C_UNIT_MEASURE and C_UNITMEASURE: return the description of a unit of measure code.
- Purchasing resolvers — C_PO_UN_NUMB, C_PO_HAZARD_CLASS, C_PO_LOOKUP: resolve United Nations number, hazard class, and other purchasing lookup meanings.
- Planning and inventory rules — C_PICK_RULES, C_ATP_RULES, C_RA_RULES, C_RA_TERMS: return descriptions for picking rules, ATP rules, and receiving/return rules and terms.
- Item and lot/serial resolvers — C_ITEM_DESCRIPTION, C_LOT_LOOKUP, C_SERIAL_LOOKUP: return item descriptions and lot or serial context values.
- Organization and HR resolvers — C_ORG_NAME, C_PER_PEOPLE: return organization names and person-related values.
- Manufacturing resolver — C_MFG_LOOKUP: returns manufacturing-related lookup meanings.
- Quantity resolver — C_QTY_ON_HAND: returns on-hand quantity values for an item context.
Parameter lists are not reproduced here; the documented behaviour is limited to returning meaning or description values keyed by code.
Tables Accessed
The package reads from a defined set of APPS-synonymed tables, all of which are natural sources of descriptive meaning:
- FND_LOOKUP_VALUES — the central lookup repository backing the C_LOOKUPS, C_FND_LOOKUP, C_FND_LOOKUP_VL, and C_FNDCOMMON functions.
- MTL_UNITS_OF_MEASURE — source for unit of measure descriptions.
- MTL_SYSTEM_ITEMS_TL and MTL_ITEM_REVISIONS_TL — translations for item descriptions and revision meanings.
- MTL_ITEM_STATUS, MTL_MATERIAL_STATUSES_TL — status code meanings.
- MTL_PICKING_RULES, MTL_ATP_RULES — planning rule descriptions.
- MTL_ONHAND_QUANTITIES_DETAIL — quantity on-hand values for C_QTY_ON_HAND.
- PO_HAZARD_CLASSES_TL, PO_UN_NUMBERS_TL — purchasing hazard and UN number meanings.
- RA_RULES, RA_TERMS — receiving/return rule and term descriptions.
Access is read-only in nature; the package resolves meanings and does not transact.
Usage Notes
INV_MEANING_SEL is referenced by six dependent packages and by a set of inventory and bill-of-material inquiry views, including BOM_EXPL_INQUIRY_VIEW, BOM_IMPL_INQUIRY_V, BOM_OP_RESOURCES_VIEW, MTL_ITEM_ATTRIBUTE_VALUES_V, MTL_SYSTEM_ITEMS_ER1_V, and MTL_SYSTEM_ITEMS_ER4_V. This dependency pattern demonstrates its primary role: supplying descriptive columns within inquiry and reporting views so that codes are presented as meanings to end users.
The package is typically invoked from these views, from Oracle Forms based on those views, and from custom concurrent programs or reports requiring code-to-meaning translation. Because it is classified as OTHER, it should be treated as an internal implementation package rather than a supported public API; customizations should avoid calling it directly where a documented public API exists. Its narrow dependency footprint makes it comparatively stable across patching, but as with all seeded APPS packages, the specification and body should be reviewed after application of EBS patches or upgrades.