Search Results gmd_qm_e_timepoints_v




Overview
Explore in AI Chat

Overview

GMD_QM_E_TIMEPOINTS_V is an Oracle E-Business Suite database view owned by the APPS schema. It belongs to the GMD product family, Process Manufacturing Product Development, and is documented with the description "OPM Quality Timepoint ERES View." The name indicates its purpose: it exposes quality management (QM) timepoint data in a form intended to support Electronic Records and Electronic Signatures (ERES) functionality, a compliance capability required for regulated process manufacturing environments subject to 21 CFR Part 11 and comparable frameworks.

In the EBS 12.1.1 and 12.2.2 releases, this object is delivered as a VALID view. It functions as a reporting and integration layer rather than a transactional entity. Because it joins timepoint scheduling data to specification header data, it allows downstream consumers — concurrent programs, ERES signature collection screens, custom reports, and interfaces — to retrieve a consolidated picture of a sampling timepoint without navigating multiple base tables. It is a read-only construct; all data manipulation occurs against the underlying base objects.

Underlying Base Objects

The view is defined over two base objects, both referenced in the ETRM metadata as synonyms:

  • GMD_SS_TIME_POINTS — the primary source, aliased as C in the view definition. It supplies the timepoint-specific attributes: variant identifier, time point identifier, specification identifier, period, name, workflow sent flag, samples per timepoint, scheduled and actual dates, sampling event, and timepoint disposition.
  • GMD_SPECIFICATIONS — aliased as I, supplying specification header attributes: specification name, version, and specification status. It is joined to the timepoint table on SPEC_ID.

Since both objects are exposed as synonyms in the APPS schema, the view resolves them within the same schema context. The relationship is one of a header-to-detail join: a specification may have multiple timepoints associated with it, and the view flattens that relationship into a single row per variant/timepoint combination.

Key Columns

  • VARIANT_ID — identifies the quality variant associated with the timepoint.
  • TIME_POINT_ID — unique identifier for the timepoint record.
  • SPEC_NAME and SPEC_VERS — specification name and version, sourced from GMD_SPECIFICATIONS.
  • SPEC_STATUS — the lifecycle status of the specification, useful for filtering to active specifications.
  • PERIOD_ID — the sampling period to which the timepoint belongs.
  • NAME — the descriptive name of the timepoint.
  • WF_SENT — indicates whether a workflow notification or approval has been dispatched, relevant to ERES workflow routing.
  • SAMPLES_PER_TIME_POINT — the number of samples required at that timepoint.
  • SCHEDULED_DATE and ACTUAL_DATE — planned versus realized sampling dates, supporting adherence reporting.
  • SAMPLING_EVENT_ID — links the timepoint to its sampling event record.
  • TIMEPOINT_DISPOSITION — the outcome or disposition applied to the timepoint.

Common Use Cases and Queries

Typical uses include building ERES compliance reports, monitoring sampling adherence, and feeding quality dashboards. A representative query enumerates timepoints for a specific specification version:

  • SELECT time_point_id, spec_name, spec_vers, name, scheduled_date, actual_date, samples_per_time_point FROM apps.gmd_qm_e_timepoints_v WHERE spec_name = :spec AND spec_vers = :vers ORDER BY scheduled_date;
  • SELECT time_point_id, sampling_event_id, timepoint_disposition, wf_sent FROM apps.gmd_qm_e_timepoints_v WHERE spec_status = 'ACTIVE' AND wf_sent = 'N'; — identifies active specifications with pending workflow communication.
  • A variance query comparing actual to scheduled dates supports overdue-sampling analysis:
  • SELECT spec_name, name, scheduled_date, actual_date FROM apps.gmd_qm_e_timepoints_v WHERE actual_date IS NULL AND scheduled_date < SYSDATE;

Because the view performs a straightforward join with no aggregation, it can be freely combined with additional specification or organization-level tables. Developers should treat it as a stable presentation layer and avoid direct DML, directing all maintenance through the GMD quality application modules.