Search Results ego_mtl_catalog_grp_vers_b




Overview
Explore in AI Chat

Overview

EGO_MTL_CATALOG_GRP_VERS_B is a base table in the EGO schema belonging to the Advanced Product Catalog module of Oracle E-Business Suite. It stores Item Catalog Category Versions data. In the catalog data model, an item catalog group defines a logical classification node (a catalog category) used to organize items for browsing, search, and publication. This table captures the versioned representation of those groups, allowing multiple successive revisions of a category definition to coexist with distinct validity windows. The table is present and valid in both EBS 12.1.1 and 12.2.2, and the documented physical schema under ETRM 12.2.2 consists of ten columns protected by one unique index.

From a Data Vault modeling perspective, the mined metadata classifies this object as standalone. The heuristic suggests modeling EGO_MTL_CATALOG_GRP_VERS_B as its own construct rather than as a dependent satellite of another entity, since it carries an independent business key (ITEM_CATALOG_GROUP_ID combined with VERSION_SEQ_ID) and only one documented outbound foreign key. In practice, however, its foreign key to MTL_ITEM_CATALOG_GROUPS_B means it functions as a versioned satellite of the parent catalog group when integrated into a warehouse model, with the validity dates acting as the effectivity timeline.

Key Information Stored

The table holds ten documented columns. The most significant are:

  • ITEM_CATALOG_GROUP_ID — identifies the parent item catalog group. This column is the foreign key to MTL_ITEM_CATALOG_GROUPS_B and forms the leading component of the business key.
  • VERSION_SEQ_ID — the version sequence number that distinguishes successive revisions of the same catalog group. It forms the trailing component of the business key.
  • VERSION_DESCRIPTION — descriptive text for the specific version, used to communicate the intent or scope of that revision.
  • START_ACTIVE_DATE and END_ACTIVE_DATE — define the effective date range during which the version is active. These columns drive date-effective querying and determine which revision is current at any point in time.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS audit columns that record who created and last modified the row and when.

Note that the documented metadata does not expose a single-column surrogate primary key. The unique index EGO_MTL_CATALOG_GRP_VERS_B_U1, defined on (ITEM_CATALOG_GROUP_ID, VERSION_SEQ_ID), is the strongest documented business-key candidate and is the composite key developers should use to address individual rows. No surrogate ID column is enumerated in the ten documented columns, so joins and lookups should rely on the composite key and the parent foreign key.

Common Use Cases and Queries

Typical uses include catalog version auditing, effectivity reporting, and resolving the current version of a category for publication or search indexing. A common pattern joins the version table to its parent group and filters on the active window:

  • Retrieve all versions for a catalog group, ordered by sequence: select from EGO_MTL_CATALOG_GRP_VERS_B where ITEM_CATALOG_GROUP_ID = :group_id order by VERSION_SEQ_ID.
  • Resolve the version effective on a given date: filter where START_ACTIVE_DATE <= :as_of and (END_ACTIVE_DATE is null or END_ACTIVE_DATE >= :as_of).
  • Reconcile versions with their parent definition by joining ITEM_CATALOG_GROUP_ID to MTL_ITEM_CATALOG_GROUPS_B.
  • Audit change history using CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, and LAST_UPDATE_DATE.

Related Objects

The most significant related objects are the parent category table and the translation and catalog structures that share the same group identifier. Documented FK relationship: EGO_MTL_CATALOG_GRP_VERS_B.ITEM_CATALOG_GROUP_ID references MTL_ITEM_CATALOG_GROUPS_B. Related tables that typically join on ITEM_CATALOG_GROUP_ID include the version translation table (EGO_MTL_CATALOG_GRP_VERS_TL), MTL_ITEM_CATALOG_GROUPS_TL for parent descriptions, and the EGO item-category assignment tables that link items to catalog groups. Public APIs in the Advanced Product Catalog module operate on the parent group and its versions, so writes should generally flow through those APIs rather than direct DML.