Search Results wip_preferences

Overview

The WIP_PREFERENCES table is a Work in Process (WIP) module object within the Oracle E-Business Suite (EBS) environment, owned by the WIP schema. It stores WIP-specific, user-level parameters that govern how individual users interact with the Work in Process application. Rather than storing transactional manufacturing data such as work orders, material issues, or resource transactions, this table functions as a configuration and personalization repository that tailors the behavior of WIP forms, concurrent programs, and inquiry screens to a given user's working context.

Each row represents a discrete preference setting, capturing the intersection of a user, an application, and optionally an inventory organization. This makes the table a natural reference point for utilities and extensions that need to determine which operating defaults apply when a specific user opens a WIP transaction or inquiry window. Because the table is documented as a standalone object with no foreign key dependencies surfaced through the mined FK structure, it is best treated as an independent reference entity rather than part of a broader normalized chain.

From a heuristic Data Vault modeling perspective, WIP_PREFERENCES is best classified as a satellite. Its grain is defined by a preference identifier tied to a user and preference type, which implies a dependent, descriptive relationship keyed to higher-level business entities (user and organization) rather than a hub or link. This classification is offered as a modeling suggestion and should be validated against the actual deployment's constraints and integration requirements.

Key Information Stored

The documented physical schema for release 12.2.2 contains twelve columns. The most significant include:

• PREFERENCE_ID — surrogate primary key defined by the WIP_PREFERENCES_PK constraint; uniquely identifies each preference row.
• USER_ID — the EBS user to whom the preference applies, forming the principal business-key candidate alongside application and preference type.
• APPLICATION_ID — identifies the owning application context, enabling the same preference type to be scoped differently across applications.
• ORGANIZATION_ID — the inventory organization scope, where a preference may be organization-specific or global.
• PREFERENCE_TYPE — the category or name of the parameter being set (for example, default WIP parameters surfaced in the user's form session).
• VALUE and VALUE_INDEX — the stored setting content and an ordering or grouping index for multi-valued preferences.
• MODULE_ID — identifies the specific module or functional area within WIP to which the preference belongs.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY — standard EBS audit columns recording who created and last modified each preference and when.

The primary key is the surrogate PREFERENCE_ID. The natural business key is effectively the combination of USER_ID, APPLICATION_ID, ORGANIZATION_ID, and PREFERENCE_TYPE, since a user's setting for a given preference should resolve uniquely within that context. Note, however, that the documented metadata provides only the surrogate PK constraint; any unique index enforcing the business key should be confirmed in the deployed database.

Common Use Cases and Queries

Typical use cases include auditing which users have personalized WIP defaults, migrating or cloning preference settings between environments, troubleshooting form behavior that appears user-specific, and building reports on WIP configuration adoption. A common diagnostic query retrieves all preferences for a given user and organization:

• SELECT preference_id, application_id, organization_id, user_id, preference_type, value FROM wip.wip_preferences WHERE user_id = :user_id ORDER BY preference_type;
• To find whether a specific preference has been overridden for an organization, filter on ORGANIZATION_ID and PREFERENCE_TYPE.
• For audit and change tracking, join to FND_USER on USER_ID and FND_APPLICATION on APPLICATION_ID to translate identifiers into recognizable names.
• For cleanup and cloning analysis, aggregate counts by PREFERENCE_TYPE and MODULE_ID to identify rarely used or orphaned settings.

Because the table is user-scoped, it is frequently consulted during concurrent program and form initialization to derive effective runtime parameters. Reporting use cases generally focus on administrative oversight rather than transactional reporting.

Related Objects

Although the mined relationship data classifies WIP_PREFERENCES as standalone, several standard EBS objects are logically associated through shared identifier columns:

• FND_USER — joined on USER_ID to resolve the preference owner.
• FND_APPLICATION — joined on APPLICATION_ID to identify the owning application.
• ORG_ORGANIZATION_DEFINITIONS and HR_ALL_ORGANIZATION_UNITS — joined on ORGANIZATION_ID for organization context.
• WIP_PARAMETERS and related WIP setup tables — consulted together when determining effective WIP defaults.
• FND_FORM_FUNCTIONS / FND_FORM — relevant when correlating a preference with the WIP form or function it affects.
• WIP module Open Interfaces and public APIs that execute DML against WIP entities may read preference values during processing.

These associations are logical rather than enforced by declared foreign keys in the documented schema, so joins should be written carefully and validated against the specific EBS release in use.