Search Results wf_sent

Overview

APPS.GMD_QM_E_TIMEPOINTS_V is a reporting and integration view within the Oracle E-Business Suite Process Manufacturing (OPM) Quality module. It exposes time point definitions associated with quality sampling events, joining specification header information to the individual time points defined against each specification. The view is catalogued in ETRM for both 12.1.1 and 12.2.2 and is owned by the APPS schema. Its role is to provide a denormalized, read-only projection that surfaces specification identity alongside scheduling attributes — most notably the SCHEDULED_DATE and the ACTUAL_DATE columns that users frequently query to determine what sampling was planned versus what actually occurred. Because it is a view rather than a base table, it carries no independent storage and reflects the current state of its underlying tables at query time, making it suitable for custom reports, concurrent programs, and downstream integrations that need time point timing information without navigating the full OPM specification data model.

Underlying Base Objects

The view is defined over two documented base objects, both referenced through synonyms in the APPS schema:

• GMD_SS_TIME_POINTS — aliased as C in the view text; supplies the time point rows, the variant and time point identifiers, period, name, workflow flag, samples-per-time-point count, scheduled and actual dates, and the sampling event identifier.
• GMD_SPECIFICATIONS — aliased as I; supplies specification name, specification version, and specification status.

The join condition is i.spec_id = c.spec_id, an equi-join on the specification identifier. This means each row of the view represents a single time point belonging to a specific specification version. The view performs no aggregation or filtering beyond the inner join, so specifications without time points, or time points whose specification row is missing, will not appear in the result set.

Key Columns

• VARIANT_ID — identifier of the specification variant to which the time point belongs.
• TIME_POINT_ID — primary identifier for the time point record within GMD_SS_TIME_POINTS.
• SPEC_NAME / SPEC_VERS — the specification name and version, retrieved from GMD_SPECIFICATIONS.
• SPEC_STATUS — lifecycle status of the parent specification.
• PERIOD_ID — reference to the period definition governing the timing interval for the time point.
• NAME — the descriptive name assigned to the time point.
• WF_SENT — workflow-sent indicator, showing whether the time point has been dispatched into an Oracle Workflow process.
• SAMPLES_PER_TIME_POINT — the number of samples required at this time point.
• SCHEDULED_DATE — the planned date for sampling.
• ACTUAL_DATE — the date on which sampling actually took place; this is the column most commonly used to compare planned versus realized sampling activity.
• SAMPLING_EVENT_ID — identifier linking the time point to its sampling event.

Common Use Cases and Queries

Typical uses include variance reporting between scheduled and actual sampling, monitoring overdue time points, and feeding sampling schedules into external laboratory or LIMS systems. A representative query to retrieve all time points for a specification, ordered by planned date, is:

SELECT spec_name, spec_vers, name,
       scheduled_date, actual_date,
       samples_per_time_point, spec_status
  FROM apps.gmd_qm_e_timepoints_v
 WHERE spec_name = :p_spec_name
 ORDER BY scheduled_date;

To identify time points where sampling has slipped, compare the two date columns:

SELECT time_point_id, spec_name, name,
       scheduled_date, actual_date,
       actual_date - scheduled_date AS slip_days
  FROM apps.gmd_qm_e_timepoints_v
 WHERE actual_date IS NOT NULL
   AND actual_date > scheduled_date;

To find outstanding time points not yet sampled and not yet sent to workflow:

SELECT time_point_id, spec_name, name, scheduled_date
  FROM apps.gmd_qm_e_timepoints_v
 WHERE actual_date IS NULL
   AND NVL(wf_sent, 'N') = 'N'
 ORDER BY scheduled_date;

Because the view joins directly to GMD_SPECIFICATIONS without filtering on SPEC_STATUS, callers should apply their own status predicates when only active or released specifications are relevant to the report.