Search Results vea_versions_pk

Overview

VEA.VEA_VERSIONS is a table owned by the VEA schema, registered in Oracle E-Business Suite as part of the VEA – Automotive product module. The ETRM metadata classifies the object with a status of VALID, but its product description is explicitly recorded as "Not currently used." This designation indicates that while the physical table exists in the 12.1.1 and 12.2.2 schemas and retains a valid, compileable definition, Oracle does not expose it through any active Automotive application flow. It is best understood as a dormant or legacy repository rather than a functional business object in the delivered application.

The heuristic Data Vault classification mined from the foreign-key structure is standalone. In Data Vault modeling terms this suggests the table functions as neither a true hub, link, nor satellite within its documented relationships: it holds its own primary key (VERSION_ID) but no foreign keys of its own are recorded, and its downstream references are effectively orphan-style joins from unrelated modules. Analysts building a vault model should treat VERSION_ID as a candidate hub key despite the absence of inbound dependencies, but should validate against live data before relying on it.

Key Information Stored

The documented physical schema for 12.2.2 lists 14 columns. The most significant are:

• VERSION_ID — the surrogate primary key, enforced by constraint VEA_VERSIONS_PK. This is the column referenced by the many downstream foreign keys.
• RELEASE_ID — likely identifies the parent release or product release context for the version row.
• VERSION_NUMBER — the human-readable business identifier for the version; a probable business-key candidate alongside RELEASE_ID, though no unique index is documented.
• LAYER_PROVIDER_CODE — a short code indicating the provider of the version layer, consistent with Automotive configuration/layer versioning concepts.
• DESCRIPTION — free-text description of the version.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS WHO audit columns.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — the standard concurrent-program tracking columns, indicating rows were historically populated by a concurrent request.

Because no foreign keys originate from VEA_VERSIONS, and no unique business index is documented beyond the primary key, VERSION_ID remains the only reliable unique identifier.

Common Use Cases and Queries

As the table is "not currently used," reporting queries are typically investigative or data-migration oriented. Typical patterns include verifying population and checking orphaned downstream references:

• Row count and date-range profiling: SELECT COUNT(*), MIN(CREATION_DATE), MAX(CREATION_DATE) FROM VEA.VEA_VERSIONS;
• Joining to dependents to confirm whether any downstream rows still point at this table, for example SELECT v.VERSION_ID, v.VERSION_NUMBER, j.VERSION_ID FROM VEA.VEA_VERSIONS v, JTS.JTS_CONFIG_VERSIONS_B j WHERE v.VERSION_ID = j.VERSION_ID;
• Cleanup or archival assessment ahead of upgrades, since a deprecated object may be a candidate for purge.

Related Objects

Numerous tables in other modules carry a VERSION_ID foreign key nominally pointing to VEA_VERSIONS. The most significant include:

• JTS_CONFIG_VERSIONS_B / JTS_CONFIG_VERSIONS_TL and JTS_CONFIG_VERSION_STATUSES — config version base, translation, and status tables joined on VERSION_ID.
• DOM_DOC_REV_VERSIONS plus its _TL and _EXT_B / _EXT_TL extensions, and DOM_DOC_PUBLISH_HIST — document revision and publishing history.
• PA_PROGRESS_REPORT_VERS and PA_SUMM_BALANCES — Projects progress-report version and summary balance tables.
• PJI_FM_EXTR_PLNVER1 and PJI_FM_EXTR_PLAN — project financial plan extraction objects.
• IGW_BUDGET_DETAILS, IGW_REPORT_ITEMIZED_BUDGET, and related IGW grants budget tables.