Search Results variance_quantity




Overview

APPS.PJM_PROJECT_PROJ_LS_LINE_SUM_V is a database view owned by the APPS schema in Oracle E-Business Suite, documented with a status of VALID in the ETRM metadata for releases 12.1.1 and 12.2.2. The view returns project-related line schedule summary information and corresponds to the Project Line web inquiry region within Oracle Projects and Oracle Manufacturing self-service pages. Per the documented metadata, the view is classified as a Web view — a construct designed to simplify access from Oracle Self-Service Web Applications — and it carries the FND Design Data identifier PJM.PJM_PROJECT_PROJ_LS_LINE_SUM_V.

The view is not a transactional base table. It is a read-oriented abstraction that aggregates planned and completed quantities at the production line level and derives the variance between them. Its principal role is to feed project line inquiry screens and to serve as a lightweight integration surface for reporting, BI Publisher data templates, and Discoverer or Oracle Analytics extracts that need project-level schedule summaries without traversing the full Projects and Manufacturing model.

Underlying Base Objects

The ETRM documentation records a single referenced base object for this view: APPS.PJM_LINE_SCHEDULES_V, itself a view in the PJM (Project Manufacturing) product family. The documented dependency tree therefore places PJM_PROJECT_PROJ_LS_LINE_SUM_V one layer above PJM_LINE_SCHEDULES_V, with the summary view projecting a restricted subset of columns from that scheduling view.

The documentation states explicitly that APPS.PJM_PROJECT_PROJ_LS_LINE_SUM_V is not referenced by any other database object. It is a terminal object in the dependency graph — consumed only by application code, concurrent programs, or ad hoc queries, never by another view or package. This detail matters during upgrades and patch analysis because changes to PJM_LINE_SCHEDULES_V will propagate into this view, but nothing downstream in the schema depends on it.

Key Columns

  • LINE_CODE (VARCHAR2(10)) — The production line code identifying the scheduling line.
  • LINE_ID (NUMBER) — The unique identifier for the production line; the primary join key back to line-level entities.
  • PROJECT_ID (NUMBER) — The system-generated number that uniquely identifies a project or seiban, linking the summary row to the Projects hierarchy.
  • PLANNED_QUANTITY (NUMBER) — The initial planned quantity established for the line.
  • QUANTITY_COMPLETED (NUMBER) — The quantity that has been completed against the line.
  • VARIANCE_QUANTITY (NUMBER) — The variance quantity, the difference between planned and completed quantities, used to monitor schedule adherence and fulfillment performance.

The variance_quantity column is the metric most frequently used for exception reporting, since it isolates lines whose completion deviates from plan without requiring the consumer to compute the difference. All six columns are exposed without mandatory-flag restrictions in the documented metadata, though LINE_CODE, LINE_ID, and PROJECT_ID function as the logical composite key for reporting purposes.

Common Use Cases and Queries

Typical usage includes project line inquiry screens, self-service dashboards showing planned-versus-completed status by production line, and scheduled reports that surface lines with nonzero variance. The view is well suited to Oracle Analytics and BI Publisher data models because its column set is narrow and its grain is one row per line per project.

To list all lines for a given project with their variance:

  • SELECT LINE_CODE, LINE_ID, PROJECT_ID, PLANNED_QUANTITY, QUANTITY_COMPLETED, VARIANCE_QUANTITY FROM APPS.PJM_PROJECT_PROJ_LS_LINE_SUM_V WHERE PROJECT_ID = :project_id;

To identify lines requiring attention, filter on the variance quantity:

  • SELECT LINE_CODE, PROJECT_ID, PLANNED_QUANTITY, QUANTITY_COMPLETED, VARIANCE_QUANTITY FROM APPS.PJM_PROJECT_PROJ_LS_LINE_SUM_V WHERE VARIANCE_QUANTITY <> 0 ORDER BY VARIANCE_QUANTITY DESC;

Because the view is documented as a Web view with no downstream dependents, customers may query it directly for diagnostics and may also build their own reporting views on top of it without risk of collateral impact within the APPS schema. All access should observe the standard APPS read-only convention applied to seeded views.