Search Results get_result_value_code




Overview
Explore in AI Chat

Overview

WIP_PREFERENCES_PKG is an Oracle Work in Process (WIP) package owned by the APPS schema that centralizes retrieval and resolution of Work in Process preference settings. Within Oracle EBS 12.1.1 and 12.2.2, WIP preferences allow organizations to control the default behavior of WIP transactions and forms at multiple scoping levels — responsibility, organization, and department. The package provides the programmatic interface used to look up preference values, determine where a preference is configured, and calculate the effective (resultant) value that applies at a given level after inheritance rules are considered.

The package is classified as OTHER in the ETRM metadata and is not documented as a public integration API. It is used internally by WIP forms, concurrent programs, and other WIP logic to resolve preference setups consistently, honoring the level hierarchy configured in the WIP preference setup tables.

Key Procedures and Functions

The documented interface exposes eleven callable units. Nine are functional getters and two return descriptive level, responsibility, organization, or department information.

  • GET_PREFERENCE_VALUE_CODE — Returns the attribute_code from WIP_PREFERENCE_VALUES for single-value preferences based on responsibility key, org_id, and dept_id. For multi-value preferences it returns "ENTERED" or "INHERIT" depending on setup.
  • GET_PREFERENCE_VALUE — Returns the attribute_value corresponding to the resolved attribute_code for a preference.
  • GET_ROW_COUNT — Returns the number of preference setups at a specified level, used to determine whether a preference is configured at that scope.
  • GET_RESULT_VALUE_CODE — Calculates the result preference value code — the effective code after applying inheritance — for a preference at a given responsibility/org/department context. This is the object the user searched for.
  • GET_RESULT_VALUE — Calculates and returns the resultant attribute_value after inheritance resolution.
  • GET_INHERIT_FLAG_VALUE — Returns the inherit flag for a preference at a specified level, indicating whether the value is inherited from a parent level.
  • GET_PREFERENCE_LEVEL_ID — Calculates the preference level_id based on the supplied responsibility key, organization id, and department id.
  • GET_LEVEL, GET_RESPONSIBILITY, GET_ORGANIZATION, GET_DEPARTMENT — Accessor functions that return the descriptive level, responsibility, organization, and department context associated with a preference, supporting display and validation in WIP preference forms.

Tables Accessed

The package reads configuration and setup data from the following documented tables (referenced via APPS synonyms):

  • WIP_PREFERENCE_DEFINITIONS — Defines each WIP preference, including its identifier and attributes.
  • WIP_PREFERENCE_LEVELS — Stores the hierarchy of levels (responsibility, organization, department) at which preferences can be set.
  • WIP_PREFERENCE_VALUES — Holds the actual attribute_code and attribute_value entries for each preference and level, including inheritance indicators.
  • MTL_PARAMETERS — Provides organization-level parameters used to validate and resolve organizational context.
  • BOM_DEPARTMENTS — Supplies department definitions used when resolving department-level preferences.
  • DUAL — Used for single-row scalar evaluations and default resolution logic.

Usage Notes

WIP_PREFERENCES_PKG is typically invoked from Oracle Forms in the Work in Process module when a user opens a WIP transaction or setup window and the form must display the currently effective preference value. The getter and result functions are called to compute the value that applies for the current responsibility, organization, and department context, and the result functions apply inheritance so that an unspecified local preference inherits from a higher level.

Concurrent programs and custom extensions may call GET_RESULT_VALUE_CODE or GET_RESULT_VALUE to apply the same preference logic outside the forms UI, ensuring consistency with standard WIP behavior. Because the package is classified as OTHER rather than an API, callers should treat its signature as subject to change across releases and should not depend on it as a formally supported public interface. The inheritance-aware result functions are the preferred entry points when the effective value, rather than a level-specific stored value, is required.