Search Results oe_ak_demand_class_v




Overview
Explore in AI Chat

Overview

OE_AK_DEMAND_CLASS_V is a lightweight, read-only database view owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Oracle Order Management (ONT) product family and exists purely to expose the set of valid demand class codes defined in the application's lookup repository. The view carries a VALID status in the data dictionary and presents the demand class values in the same canonical form used by Oracle EBS list-of-values mechanisms.

Demand classes are a fundamental order management and planning concept. They allow organizations to categorize demand by source, business channel, or priority — for example distinguishing forecast demand from actual sales order demand, or separating internal, intercompany, and external consumption. Because demand class drives reservation, scheduling, and available-to-promise logic in Order Management and Oracle Advanced Supply Chain Planning, applications and integrations frequently need to enumerate the permitted demand class codes. OE_AK_DEMAND_CLASS_V provides exactly that enumeration, and it is often the object referenced by the Oracle Application Framework (OAF) "AK" style lookups used on order entry pages.

The view is a single-column projection. It applies no joins, no aggregation, and no filtering other than the lookup type predicate, which keeps it extremely cheap to query at runtime and safe to expose to integration layers.

Underlying Base Objects

Per the documented ETRM metadata for 12.2.2, OE_AK_DEMAND_CLASS_V is defined over a single referenced base object: the OE_LOOKUPS view. In Oracle EBS, OE_LOOKUPS is itself a view over the core lookup table FND_LOOKUP_VALUES (and, historically, its pre-11i antecedent). It presents lookup codes in the Order Management domain, filtered and formatted so that seeded lookup types are exposed with their enabled values.

The view definition is minimal and explicit:

Because OE_LOOKUPS resolves against the FND lookup infrastructure, the values returned reflect only lookups that are currently enabled in the application. Disabling or end-dating a lookup value in the Lookup Codes form (Application Developer responsibility) automatically removes it from this view, which means the view is inherently locale- and configuration-aware without any additional logic. Note that the view text does not filter on VIEW_APPLICATION_ID or territory, so any enabled value under the DEMAND_CLASS_CODE lookup type is returned regardless of the application that owns it.

Key Columns

The view exposes a single column:

  • DEMAND_CLASS_CODE (VARCHAR2) — the enabled lookup code from the DEMAND_CLASS_CODE lookup type. This is the stored value that Order Management writes to demand-class columns elsewhere in the schema, such as OE_ORDER_LINES_ALL.DEMAND_CLASS_CODE and OE_ORDER_HEADERS_ALL.DEMAND_CLASS_CODE, and that planning and shipping logic interprets. Values are seeded by Oracle (for example, the standard set includes codes representing normal, expedited, and forecast-style demand) and may be extended by the implementing organization through the Lookups form.

No display name, description, or enabled-flag column is exposed. Consumers that need the translated meaning of a code must join back to the underlying lookup definition.

Common Use Cases and Queries

The most common use is populating a selection list or validation list in a custom form, OAF page, or integration mapping. The trivial enumeration query is:

  • SELECT demand_class_code FROM oe_ak_demand_class_v ORDER BY demand_class_code;
  • Validating an inbound value: SELECT 1 FROM oe_ak_demand_class_v WHERE demand_class_code = :p_code;

When the business meaning is required alongside the code, the view is typically joined to FND_LOOKUP_VALUES:

  • SELECT d.demand_class_code, l.meaning, l.description
    FROM oe_ak_demand_class_v d, fnd_lookup_values l
    WHERE l.lookup_type = 'DEMAND_CLASS_CODE' AND l.lookup_code = d.demand_class_code;

Reporting queries commonly use the view as a driver to reconcile order-line demand classes against the master list, ensuring no dormant or retired codes remain assigned to open lines. Integration developers also use it as a fast, dependency-free source of truth for the demand class dimension when staging data for a planning interface.