Search Results gmd_recipe_orgn_resources




Overview

GMD_RECIPE_ORGN_RESOURCES is a Process Manufacturing Product Development (GMD) table in the Oracle E-Business Suite 12.1.1 and 12.2.2 environments. It resides in the GMD schema and stores updates to operation resources at the recipe level, capturing how individual operation line resources are configured, quantified, and parameterized when an organization-specific recipe version is created or maintained. In the Oracle Process Manufacturing (OPM) model, recipes define how products are manufactured, and operations within a recipe routing consume resources such as equipment, labor, utilities, and time. This table records the resource-level detail that applies to a given recipe, organization, routing step, and operation line, bridging master routing resource definitions with organization-specific recipe execution data.

From a modeling perspective, the ETRM metadata classifies this object heuristically as standalone, meaning no foreign key relationships to other tables were mined from the constraint structure. A Data Vault-style suggestion would therefore treat it as a standalone hub or reference table, with the composite primary key acting as the business key and all descriptive columns behaving as satellite attributes. This classification is a modeling heuristic rather than a statement about referential integrity in the underlying application, since Oracle EBS implementations frequently enforce relationships through application logic rather than database constraints.

Key Information Stored

The table contains 56 documented columns, of which the following are the most significant for integration and reporting purposes:

The surrogate primary key GMD_RECIPE_ORGN_RESOURCES_PK is composed of (RECIPE_ID, ORGN_CODE, ROUTINGSTEP_ID, OPRN_LINE_ID, RESOURCES). No separate unique indexes beyond this primary key are documented, so the composite key itself is the business-key candidate and enforces uniqueness of a resource within a recipe/organization/routing-step/operation-line combination. Note the documented metadata does not include ORGANIZATION_ID in the primary key even though the ORGANIZATION_ID column exists, which is worth validating per implementation.

Common Use Cases and Queries

Typical use cases include recipe resource cost rollups, plant capacity analysis, resource utilization reporting, and migration or validation comparisons between master routing resources and recipe-level overrides. A common query pattern retrieves all resources configured for a recipe in an organization:

  • SELECT recipe_id, orgn_code, routingstep_id, oprn_line_id, resources, resource_usage, process_qty FROM gmd_recipe_orgn_resources WHERE recipe_id = :recipe_id AND orgn_code = :orgn_code;
  • Capacity boundary reporting: SELECT resources, MIN_CAPACITY, MAX_CAPACITY FROM gmd_recipe_orgn_resources WHERE orgn_code = :orgn_code ORDER BY resources;
  • Reconciliation against routing: join to GMD_ROUTING_STEPS / operations on ROUTINGSTEP_ID and OPRN_LINE_ID to confirm resource definitions align with routing definitions.
  • Audit reporting on last changes: filter on LAST_UPDATE_DATE and LAST_UPDATED_BY to trace who modified resource parameters.

Related Objects

The metadata reports no mined foreign keys, so relationships with other GMD objects are maintained via application logic. Significant related objects include:

  • GMD_RECIPES — joined on RECIPE_ID to obtain recipe header information; the parent business entity for this table.
  • GMD_RECIPE_ORGN_HEADERS / organization-level recipe tables — joined on RECIPE_ID and ORGN_CODE for organization-specific recipe context.
  • GMD_ROUTING_STEPS and operation/routing step tables — joined on ROUTINGSTEP_ID and OPRN_LINE_ID.
  • GMD_OPERATION_RESOURCES — the master operation resource definitions that this table updates or overrides at recipe level.
  • GMD_ORGANIZATION_RESOURCES / resource master data — joined on RESOURCES to retrieve resource descriptions and units.
  • MTL_SYSTEM_ITEMS_B — when resources map to inventory items, joined on the item organization to resolve resource identity.

Because this table is standalone from a constraint perspective, all such joins are convention-based rather than FK-enforced, and consumers should validate key coverage before relying on referential integrity assumptions.