Skip to content
Fusion Reference

EGP_ITEM_REVISIONS_B

Product: EGPmasterPer inventory org

Item revisions — one row per revision level of an item in an organization, with effectivity and implementation dates and the change-order line that introduced it

Identity
Module: Product MasterInventory-org partitioned (ORGANIZATION_ID)
Notes

REVISION_ID is the surrogate key; the business key is item + org + revision. No BICC extract data store covers revisions in the documented catalog — the OTBI Item Revisions subject area is the delivered reporting path (see the extract map verdicts in the plan doc).

What the badges mean
Product: EGP
Product: the Oracle product family that owns the object — the short code Oracle's Tables and Views documentation lists as the object owner. Fusion is SaaS, so this isn't a database schema; there's no SQL path to the tables at all (see the quirks guide).
master
Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or a documented view.

Structural facts — how the table is partitioned, not a trap by itself

BU-striped (ORG_ID)
Rows are scoped to a business unit. The column is still named ORG_ID, but in Fusion it means business unit, not the EBS operating unit — treat any migrated “operating unit” filter as suspect (see the quirks guide).
Per inventory org
Rows are scoped to an inventory organization via ORGANIZATION_ID — always pair it with INVENTORY_ITEM_ID on item-level joins (see the quirks guide).
Set / ledger / named-BU striped
Some tables stripe by a named column instead of ORG_ID: reference data set (SET_ID — see the quirks guide), ledger (LEDGER_ID on the GL journal tables), or a named business-unit column (PRC_BU_ID / REQ_BU_ID in procurement). The table page’s partition line names the column, and the generated SQL anchors on it — never treat these tables as unpartitioned.
Language-striped
The table carries a LANGUAGE column (a _TL translation table or FND_LOOKUP_VALUES) — one row per language. Filter to one LANGUAGE or a join multiplies rows.

Join & extract hazards — verify before you rely on this

Date-effective
This is an _F table — one row per entity per effectivity window, with EFFECTIVE_START_DATE and EFFECTIVE_END_DATE part of the key. Join without a window filter and every fact multiplies by history (see the quirks guide).
View
This is a documented convenience view, not a physical table. Extract through the BICC data store that fronts its base objects instead of assuming the view lands as-is.
In field listings, the Key chip marks a key field — a member of the documented primary key or of a documented unique index.

Fields

10 fields · 4 key

10 fields.

Table fields: position, field name, description, data type, and flags. 10 fields.
#FieldDescriptionTypeFlags
1REVISION_IDSurrogate key of the revisionNUMBER
Key
2INVENTORY_ITEM_IDItem the revision belongs to — part of the natural unique keyNUMBER
Key
3ORGANIZATION_IDOrganization the revision is defined in — part of the natural unique keyNUMBER
Key
4REVISIONRevision code (A, B, C…) — part of the natural unique keyVARCHAR2
Key
5EFFECTIVITY_DATEWhen the revision becomes effectiveDATE
Filter date
6END_EFFECTIVITY_DATEWhen the revision stops being effectiveDATE
7IMPLEMENTATION_DATEWhen the revision was implemented — NULL while pending on a change orderDATE
8REVISION_REASONReason code for creating the revisionVARCHAR2
9CURRENT_PHASE_IDLifecycle phase of the revisionNUMBER
10CHANGE_LINE_IDChange-order line that created the revisionNUMBER

Field provenance: hand-curated. 4 key fields.

Boilerplate SQL

Starting point for reading the BICC-landed copy of EGP_ITEM_REVISIONS_B on Databricks — real DATE columns need no conversion, and the org anchor and the LAST_UPDATE_DATE watermark (the column incremental BICC extracts key on) are already in place. Set your Unity Catalog location, schema, and org values below; they’re substituted into the SQL and the copy button.

Query parameters

9 parameters not filled: <catalog>, <schema>, <inventory_org_id>, <REVISION_ID>, <INVENTORY_ITEM_ID>, <REVISION>, <DATE_FROM>, <DATE_TO>, <watermark>

-- ============================================================
-- Table  : EGP_ITEM_REVISIONS_B — Item revisions — one row per revision level of an item in an organization, with effectivity and implementation dates and the change-order line that introduced it
-- Purpose: Column-selected read of EGP_ITEM_REVISIONS_B — auto-generated from field metadata
-- Grain  : One row per inventory org (ORGANIZATION_ID) + REVISION_ID + INVENTORY_ITEM_ID + REVISION
-- Notes  : Auto-generated skeleton for Oracle Fusion Cloud data landed in your lakehouse by a BICC extract — there is no SQL path to the SaaS database. Column names follow Oracle's table documentation — if your landed data still carries PVO attribute headers, map names first; see quirks #pvo-drift. Dates are real DATE/TIMESTAMP columns — no conversion needed. WHO audit columns omitted (see the quirks guide); the optional LAST_UPDATE_DATE watermark filter supports incremental extracts.
-- ============================================================
SELECT
  t.REVISION_ID AS "Surrogate key of the revision",
  t.INVENTORY_ITEM_ID AS "Item the revision belongs to — part of the natural unique key",
  t.ORGANIZATION_ID AS "Organization the revision is defined in — part of the natural unique key",
  t.REVISION AS "Revision code (A, B, C…) — part of the natural unique key",
  t.EFFECTIVITY_DATE AS "When the revision becomes effective",
  t.END_EFFECTIVITY_DATE AS "When the revision stops being effective",
  t.IMPLEMENTATION_DATE AS "When the revision was implemented — NULL while pending on a change order",
  t.REVISION_REASON AS "Reason code for creating the revision",
  t.CURRENT_PHASE_ID AS "Lifecycle phase of the revision",
  t.CHANGE_LINE_ID AS "Change-order line that created the revision"
FROM <catalog>.<schema>.EGP_ITEM_REVISIONS_B t
WHERE
  t.ORGANIZATION_ID = <inventory_org_id>  -- inventory org, NOT the business unit — see quirks guide #item-org-striping
  -- AND t.REVISION_ID = <REVISION_ID>
  -- AND t.INVENTORY_ITEM_ID = <INVENTORY_ITEM_ID>
  -- AND t.REVISION = '<REVISION>'
  -- AND t.EFFECTIVITY_DATE >= DATE '<DATE_FROM>'
  -- AND t.EFFECTIVITY_DATE <= DATE '<DATE_TO>'
  -- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>'  -- the column incremental BICC extracts key on
ORDER BY t.REVISION_ID;

Verified September 2026 · docs release 26C

Column names differ in BICC extracts — see PVO header drift.

Relationships

Diagram of 1-hop neighbors — join details below. FND lookup decode and translation edges are highlighted; they’re the joins newcomers most often get wrong.

Join details

  • EGP_ITEM_REVISIONS_BEGP_SYSTEM_ITEMS_Bforeign key · N:1
    ON EGP_ITEM_REVISIONS_B.INVENTORY_ITEM_ID = EGP_SYSTEM_ITEMS_B.INVENTORY_ITEM_ID AND EGP_ITEM_REVISIONS_B.ORGANIZATION_ID = EGP_SYSTEM_ITEMS_B.ORGANIZATION_ID

Browse more Product Master tables

More Product Master tables

Maintained by Summit Analytics, a supply chain analytics practice. The tools and references are free — the consulting is selective.

Part of the Summit Analytics reference library.

Work with the practice

Not affiliated with or endorsed by Oracle. Oracle and Oracle Fusion Cloud Applications are registered trademarks of Oracle and/or its affiliates.