Search Results vea_exceptions




Overview
Explore in AI Chat

Overview

VEA_EXCEPTIONS is a transactional table in the Oracle E-Business Suite Automotive (VEA) product module. Its documented purpose is to store exception message details generated during automotive processing, such as order import, scheduling, and fulfillment flows. In EBS 12.1.1 and 12.2.2, the table resides in the VEA schema and is classified as VALID in the ETRM repository.

The mined Data Vault classification for this object is standalone, meaning the FK structure does not tie it into a parent-child hub/link/satellite chain. As a modeling suggestion, this positions VEA_EXCEPTIONS as a candidate satellite or reference-style entity rather than a true hub or link: it captures descriptive exception payload rows keyed by a surrogate identifier, without enforced foreign-key dependency to other business entities. The absence of downstream FK relationships reinforces its role as a self-contained exception log tied back to source records through denormalized attributes such as RELEASE_ID and LAYER_PROVIDER_CODE rather than through declared constraints.

Key Information Stored

The table is documented with 16 physical columns in the 12.2.2 schema. The most significant are:

The surrogate PK (EXCEPTION_ID) is distinct from any business-key candidate in the strict sense; here the unique index VEA_EXCEPTIONS_U1 happens to align with the PK column, so EXCEPTION_ID serves both roles.

Common Use Cases and Queries

Typical use cases include diagnosing failed automotive processing, monitoring exception volume by release, and building exception dashboards for order or scheduling flows. A representative query retrieving recent exception detail is:

  • SELECT exception_id, release_id, layer_provider_code, message_name, exception_level, message_text FROM vea.vea_exceptions WHERE release_id = :p_release_id ORDER BY creation_date DESC;
  • SELECT exception_level, COUNT(*) FROM vea.vea_exceptions WHERE creation_date >= :p_from_date GROUP BY exception_level; for trend and severity reporting.
  • Correlating exceptions to the generating concurrent request: SELECT e.exception_id, e.message_text, r.request_id FROM vea.vea_exceptions e, fnd_concurrent_requests r WHERE e.request_id = r.request_id;

Related Objects

The documented relationship data shows no outgoing or incoming foreign keys, consistent with the standalone classification. Related objects are therefore inferred by shared attributes rather than declarative constraints:

  • FND_CONCURRENT_REQUESTS — joined on REQUEST_ID to trace the originating concurrent program run.
  • FND_CONCURRENT_PROGRAMS — joined on PROGRAM_ID, PROGRAM_APPLICATION_ID to resolve the program name.
  • VEA release and layer entities — referenced via RELEASE_ID and LAYER_PROVIDER_CODE, typically through the VEA order import and scheduling tables in the same schema.
  • FND_USER — joined on CREATED_BY and LAST_UPDATED_BY for audit attribution.

Because referential integrity is not enforced by FK constraints, joins to these objects should be validated at the application or query level rather than assumed.