Results for “gmd_status_b”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

GMD_STATUS_B is the base table for status code definitions within the Oracle EBS Process Manufacturing Product Development module (GMD). It resides in the GMD schema and stores the master list of status codes that govern the lifecycle of process manufacturing entities such as formulas, recipes, specifications, and quality results. Each row represents a single, reusable status definition — for example New, Approved, Pending Approval, or Rejected — that other GMD objects reference when recording state transitions.

From a Data Vault modeling perspective, the metadata classifies this object as hub-leaning. That classification is a heuristic suggestion: STATUS_CODE functions as a stable business key around which status identity is anchored, while descriptive and auditing attributes sit on the same physical table. In practice this means GMD_STATUS_B behaves like a reference hub with satellite-like descriptive columns co-located, rather than a pure transactional link table.

Key Information Stored

The table carries 42 documented columns in ETRM 12.2.2, but the semantic weight is concentrated in a small subset:

• STATUS_CODE — the business identifier for the status, and the sole column in the documented unique index GMD_STATUS_B_PK. This is effectively the business-key candidate.
• ZD_EDITION_NAME — the editioning column. The unique index is documented as GMD_STATUS_B_PK (STATUS_CODE, ZD_EDITION_NAME), reflecting Edition-Based Redefinition support in 12.2.x. Note this index is the business-key candidate rather than a single-column surrogate.
• STATUS_TYPE — categorises the status, allowing the application to group codes by their functional role.
• UPDATEABLE — a flag indicating whether an entity may transition out of this status, driving application-level workflow logic.
• VERSION_ENABLED — indicates whether versioning applies for entities at this status.
• DELETE_MARK — the standard EBS soft-delete indicator; rows are logically retired rather than physically removed.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Oracle who-did-what auditing columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE30 — the standard extensibility (DDF) columns reserved for customer-defined descriptive flexfield segments.

Only STATUS_CODE and ZD_EDITION_NAME participate in the documented unique index; all other descriptive columns are non-key. The surrogate-vs-business-key distinction here is noteworthy: the documented unique constraint is composite, so STATUS_CODE alone behaves as the functional business key while editioning supplies physical uniqueness.

Common Use Cases and Queries

The most frequent pattern is decoding a status code held on a transactional entity into its descriptive meaning for reporting:

• Listing all active, updatable statuses for application setup or migration validation.
• Joining GMD_STATUS_B to formula, recipe, or specification tables via STATUS_CODE to render human-readable state labels in operational reports.
• Feeding status transitions into obligation or approval analyses by combining UPDATEABLE with the transition rules in GMD_STATUS_NEXT.

A representative query follows:

SELECT s.STATUS_CODE, s.STATUS_TYPE, s.UPDATEABLE, s.VERSION_ENABLED FROM GMD.GMD_STATUS_B s WHERE s.DELETE_MARK = 0 ORDER BY s.STATUS_CODE;

Because DELETE_MARK is the soft-delete control, virtually every production query should filter on it. Multi-org or edition-aware queries must also constrain ZD_EDITION_NAME where applicable.

Related Objects

The documented foreign-key relationships point inward from a single transition table, GMD_STATUS_NEXT, which models the permitted movement between statuses:

• GMD_STATUS_NEXT.CURRENT_STATUS → GMD_STATUS_B — the status an entity is moving from.
• GMD_STATUS_NEXT.TARGET_STATUS → GMD_STATUS_B — the status an entity is moving to.
• GMD_STATUS_NEXT.PENDING_STATUS → GMD_STATUS_B — an intermediate or held status.
• GMD_STATUS_NEXT.REWORK_STATUS → GMD_STATUS_B — the status assigned when an entity requires rework.

Together these four columns make GMD_STATUS_NEXT the primary dependent object, and it is the principal join path for any workflow-transition analysis. Beyond these documented relationships, GMD_STATUS_B is referenced indirectly by the GMD entity tables (formulas, recipes, specifications, and quality objects) that carry a STATUS_CODE column validated against this base table.