Search Results vea_exceptions_u1

Overview

VEA.VEA_EXCEPTIONS is a seed-data table in the Oracle E-Business Suite Trading Partner Toolkit (VEA) schema. It functions as the central repository for exception messages generated during the operation of the Trading Partner Toolkit, which is the framework EBS uses to model and validate business-to-business (B2B) message exchanges such as EDI transactions processed through Oracle e-Commerce Gateway and related partner integration flows. Each row captures a discrete exception produced during toolkit processing, associating the message with a specific release, originating layer or provider, and severity level.

The table resides in the APPS_TS_SEED tablespace with PCT Free of 10, reflecting its role as a seeded configuration and message-catalog object rather than a high-volume transactional ledger. It is owned by the VEA schema and registered under FND Design Data as VEA.VEA_EXCEPTIONS, and is documented as VALID in both 12.1.1 and 12.2.2.

From a Data Vault modeling perspective, the mined relationship structure classifies VEA_EXCEPTIONS as a standalone object. This is a heuristic classification: with no foreign keys referencing external parents and no child links declared, the table behaves as a self-contained reference or lookup hub rather than a link table joining multiple business entities. In practice it is closer to a reference satellite of exception-message metadata, keyed by its own surrogate identifier.

Key Information Stored

The table contains 16 documented columns. The single-column unique index VEA_EXCEPTIONS_U1 on EXCEPTION_ID is the business-key candidate, and the primary key constraint PK_VEA_EXCEPTIONS also covers EXCEPTION_ID. This surrogate number uniquely identifies each exception record and is the value retrieved by the user's search term "vea_exceptions_u1."

• EXCEPTION_ID — Numeric primary key and the column underpinning the VEA_EXCEPTIONS_U1 unique index; the unique identifier for each exception.
• RELEASE_ID — Numeric identifier tying the exception to a specific toolkit or product release, allowing message sets to be versioned.
• LAYER_PROVIDER_CODE — VARCHAR2(30) identifying the layer developer or provider that raised the exception, useful for isolating defects to a partner or extension.
• MESSAGE_NAME — VARCHAR2(30) logical name of the message, used to reference the exception programmatically.
• EXCEPTION_LEVEL — Severity indicator (for example error, warning, or information) that classifies the exception's impact.
• MESSAGE_TEXT — VARCHAR2(2000) the rendered exception text presented to users or written to logs.
• DESCRIPTION — VARCHAR2(1000) supplementary description of the message and its meaning.
• Standard Who columns — CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN provide the standard audit trail.
• Concurrent program columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE capture the concurrent request context that produced the row.

Common Use Cases and Queries

Typical scenarios include enumerating all severity levels defined for a release, resolving a MESSAGE_NAME to its display text during troubleshooting, and auditing which provider codes generate the most exceptions. The documented access path is a direct select or an indexed lookup by EXCEPTION_ID:

• Lookup by surrogate key: SELECT message_name, exception_level, message_text FROM vea.vea_exceptions WHERE exception_id = :p_id;
• Messages for a release: SELECT exception_id, message_name, exception_level FROM vea.vea_exceptions WHERE release_id = :p_release ORDER BY exception_id;
• Exceptions raised by a provider: SELECT layer_provider_code, exception_level, COUNT(*) FROM vea.vea_exceptions WHERE layer_provider_code = :p_code GROUP BY layer_provider_code, exception_level;
• Concurrent-request traceability: join REQUEST_ID to FND_CONCURRENT_REQUESTS to correlate an exception with the program run that produced it.

Because the table is seeded reference data in APPS_TS_SEED, reporting is usually read-only; direct DML should be avoided in favor of supported toolkit configuration paths.

Related Objects

The metadata records that VEA_EXCEPTIONS does not reference any database object and is referenced only by the VEA schema object VEA_EXCEPTIONS# (the underlying table segment). Practical dependencies therefore center on the Trading Partner Toolkit and standard EBS infrastructure rather than declared foreign keys:

• VEA.VEA_EXCEPTIONS# — the underlying segment referenced by the synonym or view of the same base name.
• VEA.VEA_EXCEPTIONS_U1 — the unique index on EXCEPTION_ID used for key access.
• PK_VEA_EXCEPTIONS — the primary key constraint on EXCEPTION_ID.
• FND_CONCURRENT_REQUESTS — joined via REQUEST_ID to identify the concurrent program run that logged an exception.
• FND_APPLICATION / FND_CONCURRENT_PROGRAMS — joined via PROGRAM_APPLICATION_ID and PROGRAM_ID to resolve the owning application and program.
• VEA schema toolkit tables and APIs — Trading Partner Toolkit validation and mapping routines that insert exception rows during message processing.

As the relationship data confirms a standalone classification, integration beyond these infrastructure joins should be treated as logical rather than enforced by foreign-key constraints.