Search Results gma_reason_code_security




Overview
Explore in AI Chat

Overview

GMA_REASON_CODE_SECURITY is a Process Manufacturing (GMA) module table within the Oracle E-Business Suite 12.1.1 and 12.2.2 environments. It functions as the Reason Code Security Table, and its purpose is to control which users, by way of their assigned responsibilities, are authorized to select specific reason codes during transaction processing. Reason codes are used throughout process manufacturing and inventory transactions — for example, to capture the business justification for a scrap, adjustment, or quality movement — and this table enforces access restrictions so that only appropriate responsibilities can apply a given reason code to a given document type.

The table resides in the GMA schema and holds a documented physical schema of eight columns in ETRM 12.2.2. Its heuristic Data Vault classification, mined from the foreign-key structure, is standalone, meaning it does not participate in a hub-and-link pattern but behaves as an independent reference or authorization entity. This classification should be treated as a modeling suggestion rather than a definitive architectural designation, since the table is not strictly a hub, link, or satellite in the Data Vault sense.

Key Information Stored

The most important columns define the security mapping that the table enforces. The business-key candidate, documented through the unique index GMA_REASON_CODE_SECURITY_U1, is the composite of three columns:

  • REASON_CODE — the reason code being secured.
  • DOC_TYPE — the document type to which the security restriction applies.
  • RESPONSIBILITY_ID — the responsibility granted access to that reason code for that document type.

Together these three columns form the unique index GMA_REASON_CODE_SECURITY_U1 and constitute the primary key (GMA_REASON_CODE_SECURITY_U1). The remaining documented columns are standard EBS audit and concurrency columns:

There is no separate surrogate primary key documented; the composite unique index serves as the identifying key.

Common Use Cases and Queries

Typical scenarios include auditing which responsibilities can apply a given reason code, identifying all reason codes restricted for a document type, and diagnosing why a user cannot select a reason code in a transaction window. A representative query joining security to responsibilities is:

  • SELECT s.REASON_CODE, s.DOC_TYPE, s.RESPONSIBILITY_ID FROM GMA.GMA_REASON_CODE_SECURITY s WHERE s.REASON_CODE = :reason_code;
  • SELECT responsibility_id, COUNT(*) FROM GMA.GMA_REASON_CODE_SECURITY GROUP BY responsibility_id ORDER BY 2 DESC;

Reporting use cases include security administration reviews, migration validation when copying reason codes between environments, and reconciliation of reason-code access against policy. Because the table is standalone, queries generally filter directly on REASON_CODE, DOC_TYPE, or RESPONSIBILITY_ID rather than traversing a normalized reference chain.

Related Objects

The documented FK/PK relationship data classifies this table as standalone, so no explicit foreign-key joins were supplied in the metadata. In practice, the columns connect to the wider GMA reason-code and EBS responsibility model. Significant related objects include:

  • GMA_REASON_CODES (or the corresponding reason-code definition table) — joined on REASON_CODE.
  • FND_RESPONSIBILITY — joined on RESPONSIBILITY_ID to resolve responsibility names.
  • FND_RESPONSIBILITY_TL — provides translated responsibility names.
  • FND_USER and FND_USER_RESP_GROUPS — resolve which users hold the secured responsibilities.
  • GMA_DOCUMENT_TYPES (or equivalent) — interprets DOC_TYPE values.
  • Reason-code entry forms and concurrent programs in the GMA module that read this table during validation.

Because the classification is heuristic, administrators should verify actual foreign-key enforcement in the target instance before relying on referential assumptions.