Search Results get_preference_value

Overview

APPS.WIP_PREFERENCES_PKG is a server-side PL/SQL package body in Oracle E-Business Suite that implements the Work in Process (WIP) preference resolution engine. WIP preferences allow manufacturing organizations to control discrete and repetitive work order behavior—such as defaulting rules, scheduling options, and material issue behavior—across multiple levels of the enterprise hierarchy. This package provides the core logic that evaluates a given preference across those hierarchy levels and returns the effective value.

The resolution model is hierarchical. A preference can be defined at the responsibility level, the organization level, or the department level. When a calling program asks for the value of a preference using a specific combination of responsibility key, organization ID, and department ID, the package determines whether a value is directly defined at that level or whether the setting is inherited from a higher level. For single-value preferences the package returns the stored attribute code, or the literal "INHERIT" when no value is defined at the requested level. For multiple-value (multi-select) preferences the package returns "ENTERED" or "INHERIT" to indicate whether the level has its own set of values or defers to its parent. The package is self-contained with respect to these tables but delegates organization and department validation to related lookups.

Key Procedures and Functions

The package exposes eleven documented functions, whose responsibilities fall into resolution, descriptive lookup, and structural lookup categories.

• GET_PREFERENCE_VALUE_CODE — Returns the raw attribute code stored for a preference at a given level, or the inheritance indicator. This is the foundational resolver described in the header comments of the source.
• GET_PREFERENCE_VALUE — Returns the display or effective value of a preference after resolution, layering on top of the code-level logic.
• GET_RESULT_VALUE_CODE and GET_RESULT_VALUE — Return the resolved preference result in code and value form respectively, typically used when a calling form or program needs the final effective setting.
• GET_INHERIT_FLAG_VALUE — Returns the flag indicating whether the requested level inherits its setting rather than defining one.
• GET_ROW_COUNT — Returns the count of preference value rows found for a given preference and level combination, used to distinguish defined from inherited settings.
• GET_PREFERENCE_LEVEL_ID — Resolves the internal level identifier corresponding to a supplied responsibility, organization, and department combination.
• GET_LEVEL, GET_RESPONSIBILITY, GET_ORGANIZATION, GET_DEPARTMENT — Return descriptive information about the level at which a preference is defined, supporting display and diagnostic logic in preference maintenance forms.

Tables Accessed

The package reads the WIP preference schema tables through APPS synonyms.

• WIP_PREFERENCE_DEFINITIONS — Defines each preference and its type (single or multiple value), consulted by the internal preference-type cursor.
• WIP_PREFERENCE_LEVELS — Stores the level keys (responsibility, organization, department) that identify where a preference value applies.
• WIP_PREFERENCE_VALUES — Stores the actual attribute values for each preference and level; this is the primary source of returned data.
• MTL_PARAMETERS — Provides organization context and validation.
• BOM_DEPARTMENTS — Provides department context and validation.
• DUAL — Used by the single-value and multi-value cursors to compute counts and decode results.

Usage Notes

WIP_PREFERENCES_PKG is an internal engine invoked by Oracle's own WIP forms and concurrent programs rather than a public API. The ETRM metadata records zero packages referencing it, indicating that its consumers are forms libraries and other EBS modules rather than dependent PL/SQL packages. Its resolution logic is typically executed when a user opens a WIP work order or maintenance form, and the form needs to determine which preference values apply to the current responsibility, organization, and department. Custom code should generally not call this package directly; instead, callers should prefer the WIP preferences UI or the officially supported APIs. Where custom resolution is unavoidable, the GET_PREFERENCE_VALUE family should be treated as read-only, and callers must pass the correct responsibility key, organization ID, and department ID to obtain a meaningful inheritance result. Because the logic relies on NVL comparisons against sentinel values, null handling at the calling level materially affects whether a preference is reported as inherited or entered.