Search Results gmd_ss_time_points_pk




Overview

GMD_SS_TIME_POINTS is a Process Manufacturing Product Development table that stores the individual time points defined within an Oracle EBS stability study. Each row represents a scheduled sampling or measurement milestone—expressed in years, months, weeks, days, or hours from the study start—at which a stability sample is expected to be drawn, tested, or evaluated. The table sits within the GMD schema alongside other stability study (SS) objects and is central to scheduling and tracking stability protocols throughout their lifecycle.

The ETRM documentation classifies GMD_SS_TIME_POINTS as a standalone object based on a heuristic analysis of its foreign key structure. From a Data Vault modeling perspective, this suggests the table behaves primarily as a hub-like entity: its identity is anchored on the surrogate primary key TIME_POINT_ID, while it also carries descriptive attributes that a dimensional modeler might choose to place in an adjacent satellite. It is not treated as a link table because it does not resolve a many-to-many relationship on its own.

Key Information Stored

The table contains 54 documented columns. The primary key is TIME_POINT_ID, backed by the unique index GMD_SS_TIME_POINTS_PK. TIME_POINT_ID is a system-generated surrogate key; no separate business-key column is documented as an alternate unique index, so the surrogate also serves as the de facto unique identifier.

Common Use Cases and Queries

Typical reporting scenarios include listing all time points for a stability variant, identifying overdue sampling, and reconciling scheduled versus actual test dates.

  • Retrieve time points for a variant: SELECT time_point_id, name, scheduled_date FROM gmd_ss_time_points WHERE variant_id = :variant AND delete_mark = 0;
  • Detect overdue samples: SELECT t.time_point_id, t.name, t.scheduled_date, t.actual_date FROM gmd_ss_time_points t WHERE t.actual_date IS NULL AND t.scheduled_date < SYSDATE AND t.delete_mark = 0;
  • Join to variants and sampling events to produce a full stability schedule extract by combining VARIANT_ID and SAMPLING_EVENT_ID with their parent tables.
  • Count samples expected per milestone using SAMPLES_PER_TIME_POINT for capacity planning.
  • Filter on WF_SENT to report which notifications have been dispatched.

Related Objects

The following objects have documented relationships to GMD_SS_TIME_POINTS:

  • GMD_SS_VARIANTS — Referenced by VARIANT_ID; the parent study variant each time point belongs to.
  • GMD_SAMPLING_EVENTS — Referenced by SAMPLING_EVENT_ID; also references TIME_POINT_ID, forming a bidirectional relationship.
  • GMD_SAMPLES — References GMD_SS_TIME_POINTS via TIME_POINT_ID, capturing actual samples drawn at each milestone.
  • GMD_SS_TIME_POINTS_PK — The unique index enforcing the primary key on TIME_POINT_ID.

Because GMD_SAMPLES and GMD_SAMPLING_EVENTS both carry TIME_POINT_ID foreign keys, GMD_SS_TIME_POINTS acts as a dependency for sample tracking and event scheduling within the stability study workflow.