Search Results oe_ar_lookups_v




Overview
Explore in AI Chat

Overview

The OE_AR_LOOKUPS_V view is an Oracle E-Business Suite (EBS) dictionary object owned by the APPS schema and associated with the ONT – Order Management product family. In EBS 12.1.1 and 12.2.2, this view presents lookup code information sourced from Oracle Receivables, exposing it within the Order Management data model. Lookups are the foundational reference data mechanism in EBS; they populate flexfields, drive validation logic, and control the set of permissible values displayed to users on order entry, pricing, and fulfillment forms.

From a reporting and integration standpoint, OE_AR_LOOKUPS_V provides a read-only, order-management-contextualized window into Receivables lookup values. Because Order Management processes such as order capture, shipping, and returns rely heavily on Receivables lookup types, exposing these values through a dedicated ONT-owned view allows reports, concurrent programs, and interfaces within the Order Management module to resolve lookup meanings without directly querying the AR base table. This preserves modular encapsulation and simplifies dependency management across the two products.

Underlying Base Objects

The view's documented definition is a straightforward projection: SELECT ... FROM AR_LOOKUPS. The single referenced base object is therefore AR_LOOKUPS, itself presented as a view in the documented metadata. No joins, unions, or filtering predicates are applied. Consequently, OE_AR_LOOKUPS_V contains exactly one row for every row in AR_LOOKUPS — there is no reduction or transformation of the underlying data. Each column in the view maps one-to-one to a column in AR_LOOKUPS, preserving values, data types, and nullability.

Because there is no WHERE clause, disabled and date-inactive lookups are also returned. Querying callers must therefore apply their own ENABLED_FLAG and date-range filters to obtain only currently effective values. This pass-through design is typical of EBS cross-product views, which exist primarily to formalize the dependency between a consuming module and a shared reference table rather than to alter content.

Key Columns

  • LOOKUP_TYPE — The lookup category, defining which business concept the code belongs to (for example, order or Receivables-specific lookup classifications). This is the primary discriminator when filtering.
  • LOOKUP_CODE — The internal stored code, used as the actual value persisted on transactional records.
  • MEANING — The user-facing display text associated with the code, typically rendered on reports in place of the raw code.
  • ENABLED_FLAG — Indicates whether the lookup is currently active (Y/N); inactive lookups remain in the table but should generally be excluded from validation.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — The effective-dating range governing when the lookup may be used.
  • DESCRIPTION — Free-text elaboration of the lookup's purpose.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — Descriptive flexfield storage columns available for client-specific extensions.
  • EXTERNALLY_VISIBLE_FLAG — Controls whether the lookup is exposed to external or self-service consumers.
  • Audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN support standard EBS audit tracing.

Common Use Cases and Queries

A frequent requirement is translating stored lookup codes into readable meanings on Order Management reports. The following query retrieves only enabled, currently effective values for a given lookup type:

SELECT lookup_code, meaning
FROM oe_ar_lookups_v
WHERE lookup_type = :p_lookup_type
AND enabled_flag = 'Y'
AND TRUNC(SYSDATE) BETWEEN NVL(start_date_active, SYSDATE)
AND NVL(end_date_active, SYSDATE);

Integrations use the view to validate inbound order data against permissible codes before interface table processing. Reporting teams also join it to order or Receivables transaction queries on LOOKUP_TYPE and LOOKUP_CODE to enrich output with descriptive text. Administrators occasionally query it to audit which lookups are disabled or expired. In all cases, callers should filter on ENABLED_FLAG and the active date range, since the view returns the full unfiltered lookup population.