Search Results oks_mschg_operations_dtls




Overview
Explore in AI Chat

Overview

OKS_MSCHG_OPERATIONS_DTLS is a Service Contracts (OKS) module table in Oracle E-Business Suite 12.1.1 and 12.2.2. The ETRM repository describes it as storing "masschange related information," meaning it holds the detail-level records that drive mass change operations executed against service contracts. In the Oracle Service Contracts architecture, mass change functionality allows a user to modify many contracts, contract lines, or line attributes simultaneously through a single batch operation. This table captures the operational instructions, target identifiers, and processing state associated with each such change, functioning as the transactional detail layer beneath the higher-level mass change request.

The table is owned by the OKS schema and is marked VALID in the ETRM registry. Its documented physical schema in 12.2.2 lists 29 columns. The metadata's heuristic Data Vault classification identifies this object as standalone, meaning it does not participate in a strongly linked hub-and-satellite structure within its immediate FK topology. Where a modeling suggestion is required, this object is best regarded as a satellite-like detail table anchored to a mass change request identifier (MRD_ID) rather than a classical Data Vault hub or link.

Key Information Stored

The table's primary key is OKS_MSCHG_OPERATIONS_DTLS_PK, defined on the ID column. This ID is a surrogate system-generated identifier, not a business key. The metadata documents two unique indexes: OKS_MSCHG_OPERATIONS_DTLS_U1 on ID, and OKS_MSCHG_OPERATIONS_DTLS_U2 on MRD_ID. The MRD_ID column is therefore the significant business-key candidate, linking each detail row back to its parent mass change request.

  • ID — surrogate primary key, uniquely identifying each detail row.
  • MRD_ID — the mass change request identifier; key business attribute and unique index U2 candidate.
  • OIE_ID — identifier for the operational or organizational entity involved in the change.
  • OLE_ID — identifier for the operational line or entity element subject to the mass change.
  • MSCHG_TYPE — the type classification of the mass change being performed.
  • ATTRIBUTE_LEVEL — indicates the level at which the change applies (for example, header, line, or sub-line).
  • QA_CHECK_YN — a Yes/No flag controlling whether quality assurance validation is applied to the operation.
  • OBJECT_VERSION_NUMBER — concurrency control column used for optimistic locking during updates.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit columns recording who created and last modified the row and when.
  • SECURITY_GROUP_ID — multi-tenant security grouping, with a foreign key to FND_SECURITY_GROUPS.
  • ATTRIBUTE1 through ATTRIBUTE15 — the standard EBS descriptive flexfield (DFF) columns, available for client-specific extensions.

Common Use Cases and Queries

Typical uses of this table involve auditing and troubleshooting mass change executions, reporting on which contracts or lines were affected, and verifying that QA checks were honored. Because MRD_ID is the business key, most queries join this table to its parent mass change request. A representative pattern retrieves all detail rows for a given request:

  • SELECT ID, MRD_ID, MSCHG_TYPE, ATTRIBUTE_LEVEL, QA_CHECK_YN FROM OKS.OKS_MSCHG_OPERATIONS_DTLS WHERE MRD_ID = :p_mrd_id;
  • Reporting the count and distribution of change types per request: SELECT MRD_ID, MSCHG_TYPE, COUNT(*) FROM OKS.OKS_MSCHG_OPERATIONS_DTLS GROUP BY MRD_ID, MSCHG_TYPE;
  • Audit queries filtering on LAST_UPDATE_DATE to identify operations modified within a date range.
  • Extracting DFF values (ATTRIBUTE1–15) for downstream reporting when custom attributes are enabled.

Because the table carries SECURITY_GROUP_ID and OBJECT_VERSION_NUMBER, any direct DML should respect multi-tenant security and concurrency rules. Direct manipulation is generally discouraged; mass changes should be initiated through the supported Service Contracts user interface or concurrent programs.

Related Objects

The documented FK relationship is to FND_SECURITY_GROUPS via SECURITY_GROUP_ID, which governs data access. The most significant related object is the parent mass change request table referenced by MRD_ID, through which this detail table is joined for transactional reporting. Additional context is provided by the OKS service contract and contract line tables reached via OIE_ID and OLE_ID, and by the standard EBS application-level objects FND_USER (via CREATED_BY and LAST_UPDATED_BY) and FND_CONCURRENT_REQUESTS for batch execution tracking. Reporting and concurrent programs within the OKS mass change framework are the primary consumers of this table.