Results for “gmd_recipe_customers”

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

Overview

GMD_RECIPE_CUSTOMERS is a table in the GMD schema belonging to the Process Manufacturing Product Development module of Oracle E-Business Suite (documented for 12.2.2 and applicable to 12.1.1). It stores recipe customer data — the association between a process manufacturing recipe and the customers for whom that recipe is valid or intended. In the context of ETRM, this object supports recipe definition and approval workflows by allowing product development users to restrict or tailor a recipe to specific customer accounts.

From a Data Vault modeling perspective, the metadata's heuristic classification identifies this object as standalone. That classification suggests it is best modeled as a link-style or standalone association entity rather than a pure hub or satellite, since the primary key is composed entirely of two foreign-key-style business identifiers rather than a single surrogate hub key. It carries transactional/audit attributes, but no independent business key of its own.

Key Information Stored

The table contains 11 documented columns. The most significant are:

• RECIPE_ID — Identifier of the process manufacturing recipe; part of the composite primary key.
• CUSTOMER_ID — Identifier of the customer associated with the recipe; part of the composite primary key.
• ORG_ID — Operating unit / organization context under which the relationship is defined (multi-org enabled).
• SITE_ID — Site-level qualifier for the customer or organization association.
• OPM_CUST_ID — The OPM (Oracle Process Manufacturing) customer identifier, which may differ from the standard CUSTOMER_ID for legacy/OPM-integrated records.
• TEXT_CODE — A descriptive or classification code providing additional context for the recipe–customer relationship.
• CREATED_BY, CREATION_DATE — Standard WHO audit columns capturing record origin.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard WHO audit columns capturing the last modification and login session.

The surrogate/composite primary key is defined by the unique index GMD_RECIPE_CUSTOMERS_PK (RECIPE_ID, CUSTOMER_ID). Because this index is composite and business-meaningful, it also serves as the business-key candidate — there is no separate documented surrogate column such as a sequence-generated ID.

Common Use Cases and Queries

Typical usage centers on determining which customers a recipe applies to, and which recipes apply to a given customer, often scoped by operating unit.

To list customers for a recipe:

• SELECT customer_id, org_id, site_id FROM gmd_recipe_customers WHERE recipe_id = :recipe_id;

To find all recipes assigned to a customer within an operating unit:

• SELECT recipe_id FROM gmd_recipe_customers WHERE customer_id = :customer_id AND org_id = :org_id;

Reporting scenarios include recipe-to-customer validation reports, customer-specific formulation audits, and data cleanup checks for orphaned recipe–customer links. Because ORG_ID is present, most production queries should filter by operating unit to respect multi-org security. Audit-driven queries can leverage LAST_UPDATE_DATE to extract incremental changes.

Related Objects

The metadata classifies this object as standalone with no explicitly documented foreign keys, so the relationships below are the most significant anticipated joins based on the documented columns:

• GMD_RECIPES — joined on RECIPE_ID to retrieve recipe header details.
• GMD_RECIPE_HEADERS / recipe header objects — parent recipe definition records.
• AR_CUSTOMERS / HZ_CUST_ACCOUNTS — joined on CUSTOMER_ID to resolve customer names and account details.
• HZ_CUST_ACCT_SITES_ALL / HZ_CUST_SITE_USES_ALL — joined on CUSTOMER_ID and SITE_ID to resolve site context.
• GMD_ORGANIZATIONS / ORG_ORGANIZATION_DEFINITIONS — joined on ORG_ID for operating unit validation.
• OPM customer master objects — related through OPM_CUST_ID for legacy OPM customer resolution.

Because no FK constraints are documented, joins are enforced logically rather than by the database, and referential integrity must be validated in application or reporting logic.