Search Results demand_class_code




Overview
Explore in AI Chat

Overview

The APPS.SO_DEMAND_CLASSES_ACTIVE_V view is a reporting and integration construct within the Oracle E-Business Suite Order Entry (OE) module. It presents the set of currently enabled Demand Class values defined in the application's common lookup repository. A Demand Class is a categorization attribute applied to order lines, inventory items, and fulfillment transactions that allows organizations to partition demand into logical groupings — for example, distinguishing "Retail," "Wholesale," "Internal," or priority-based demand categories. Downstream planning engines such as Oracle Advanced Supply Chain Planning and inventory allocation logic consume the demand class attribute to drive sourcing, reservation, and prioritization decisions. Because the view filters on the lookup's enabled flag and active date range relative to the current system date, it exposes only the demand class codes that are valid for use at the moment of query execution. This makes it particularly suited for list-of-values population, reporting joins, and integration interfaces that must reject obsolete or disabled classifications.

Underlying Base Objects

The view is defined over two documented base objects. The primary source is FND_COMMON_LOOKUPS (itself a view over the FND application's lookup infrastructure), from which the actual demand class records are drawn. Filtering is applied on LOOKUP_TYPE = 'DEMAND_CLASS' and APPLICATION_ID = 700, where 700 corresponds to the Oracle Order Entry application. The ENABLED_FLAG = 'Y' predicate restricts output to active lookups, while the date expression TRUNC(SYSDATE) BETWEEN NVL(START_DATE_ACTIVE, TRUNC(SYSDATE)) AND NVL(END_DATE_ACTIVE, TRUNC(SYSDATE)) enforces the effective-dating window; lookups with no start or end date are treated as open-ended. The secondary reference is FND_GLOBAL, a package that supplies session context such as the current application and responsibility identifiers, ensuring lookups are resolved within the proper application scope. Because the view reads from shared lookup tables rather than a dedicated demand class entity, any maintenance of demand class codes is performed through the standard Application Developer responsibility's Lookup Codes form rather than an Order Entry setup screen.

Key Columns

  • DEMAND_CLASS — The user-facing name of the demand class, sourced from the MEANING column of FND_COMMON_LOOKUPS. This is the value typically displayed in reports and list-of-values windows.
  • DEMAND_CLASS_CODE — The internal lookup code that uniquely identifies the demand class within the DEMAND_CLASS lookup type. Foreign-key references on transactional tables (for example, demand class columns on order lines or inventory items) store this code, not the meaning. Searches for "demand_class_code" resolve to this column.
  • DESCRIPTION — A free-form descriptive field offering extended narrative about the demand class, drawn directly from the underlying lookup record. It is optional and may be null for many configured values.

Common Use Cases and Queries

The view is frequently joined to transactional tables to decorate order line or item records with a readable demand class name. A typical pattern retrieves the enabled demand classes for a list-of-values or validation interface:

  • SELECT demand_class, demand_class_code, description FROM apps.so_demand_classes_active_v ORDER BY demand_class; — Populates a selection list with only currently active demand classes.
  • SELECT o.header_id, o.demand_class_code, v.demand_class FROM oe_order_lines_all o, apps.so_demand_classes_active_v v WHERE o.demand_class_code = v.demand_class_code; — Joins order lines to the view to display descriptive demand class names, automatically excluding lines whose codes have since been disabled.
  • SELECT demand_class_code FROM apps.so_demand_classes_active_v WHERE demand_class_code = 'RETAIL'; — Validates that a given code is valid and active before an inbound interface inserts an order line.

Because effectiveness is calculated against SYSDATE, the view's result set naturally changes as start and end dates are reached, making it well suited to scheduled extracts and integration batch processes. It should not be relied upon for historical reporting of demand class values that were active in the past; for that purpose, the base FND_COMMON_LOOKUPS table queried without the active-date predicate is more appropriate.